-
Type: Task
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Component/s: None
-
None
This change affects how clients will see the results of a {$meta: "sortKey"} projection or a {$meta: "sortKey"} aggregation expression. From a quick search, I didn't find any documentation for this feature, but if there are examples in the documentation, they should be upgraded to show the new format. A release note about the change might be warranted as well.
Previously, the result of {$meta: "sortKey"} would look like:
With this change in place the same sort key will look like this:
["first component", "second component", ..., "last component"]
I don't think any drivers are relying on the format of the sort key, but if they are, they will likely need minor compatibility fixes. Message me or the server-query Slack channel, and we can work out the details. Thanks!
Description of Linked Ticket
If a document has a compound sort key (e.g.:
{"": 1, "": 2}) and an expression tries to manipulate it, the result may only take one of the fields into account. For example, if the user tries to use {$objectToArray: {$meta: "sortKey"}}, the resulting array only has the first element (
{k: "", v: 1}).
I haven't encountered any cases yet, but it's possible that as we use Document/Value more we'll run into internal cases where we are manipulating Documents with duplicate fields.
In general, there is no invariant that all field names in a BSONObj are unique, but the only safe way to have a Document with duplicate field names is when you create it from a BSONObj and convert back to a BSONObj with no transformations (so that the lazy conversion behavior just returns the original BSONObj).
- depends on
-
SERVER-43669 $meta:"sortKey" expressions can generate BSON with duplicate field names which are not correctly handled by Document/Value class
- Closed