-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Properly implement support for Cosmos hierarchical partition keys #34557
Conversation
""" | ||
SELECT VALUE c | ||
FROM root c | ||
WHERE (c["$type"] IN ("HierarchicalPartitionKeyEntity", "DerivedHierarchicalPartitionKeyEntity") AND c["PartitionKey3"]) | ||
"""); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need a way of asserting the partition key that was passed with the query. Should I file an issue for it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was thinking the same thing. I verified this by debugging in and checking what actual partition key gets constructed, but we need something better.
AssertSql( | ||
""" | ||
SELECT VALUE c | ||
FROM root c | ||
WHERE ((c["$type"] = "HierarchicalPartitionKeyEntity") AND ((c["PartitionKey1"] = "PK1") AND (c["PartitionKey2"] = 1))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really should have caught this when I was working on these tests and looking at the baselines!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least we found it before shipping. :-D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well I should have caught this while writing all this :/
? source.Provider.CreateQuery<TEntity>( | ||
Expression.Call( | ||
instance: null, | ||
method: WithPartitionKeyMethodInfo1.MakeGenericMethod(typeof(TEntity)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider removing the MakeGenericMethod
by leveraging the compiler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're referring to this pattern, right?
That's a good suggestion... Currently all of our operators work with MakeGenericMethod, so I propose to do this in a big pass for 10... Opened #34559.
8d28101
to
9e24836
Compare
…tnet#34557) Fixes dotnet#34553 (cherry picked from commit a72420c)
This allow partial Cosmos hierarchical partition keys to be used properly, so that if only the 1st part of a partition key is specified by the user, it is properly lifted and passed to the Cosmos SDK (we were previously doing this only if the full partition key was specified).
Implementation notes:
Note that this also changes the WithPartitionKey to not use
params object[]
; that becomes an array parameter, which means that during compilation we can't know how many values were provided, and therefore whether all values are provided (necessary to know whether we can transform to ReadItem). Instead, we just have multiple overloads for 1, 2, and 3 partition key values.Fixes #34553