[SERVER-23924] Make _id index inherit the collection's default collation Created: 25/Apr/16 Updated: 22/Jun/17 Resolved: 08/Jul/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying, Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.3.10 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | J Rassi | Assignee: | Tess Avitabile (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Sprint: | Query 16 (06/24/16), Query 17 (07/15/16) | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
| Comments |
| Comment by Githook User [ 08/Jul/16 ] |
|
Author: {u'username': u'tessavitabile', u'name': u'Tess Avitabile', u'email': u'tess.avitabile@mongodb.com'}Message: |
| Comment by J Rassi [ 26/Apr/16 ] |
Ah, by "a non-default collation" I meant "a collation other than the default binary collation". I've edited my comment above to clarify.
Prohibiting users from being able to specify a collation on the _id index other than the collection default saves some amount of development time and presents a simpler user interface, and we didn't come up with good use cases for it. That said, even having the _id index take on a collation other than the simple binary collation isn't going to be easy, so this ticket proposes one alternative of cutting scope where the _id index always takes on the simple binary collation, regardless of the collection default. I think we could discuss this more efficiently in person, so I'd rather meet up to decide instead of continuing to hash this out in ticket comments. |
| Comment by Eric Milkie [ 26/Apr/16 ] |
|
I'm not sure what you mean by "_id index to have a non-default collation." Is "non-default collation" the same thing as "not the collation on the collection"? |
| Comment by J Rassi [ 26/Apr/16 ] |
|
We're currently thinking about making the _id index take on the collection default collation, and not exposing any new _id-specific collection options or allow rebuilding of the _id index. We do understand that this may require some difficult replication work, and we could consider scrapping this idea and forcing the _id to always have the default binary collation. Let's talk in person sometime in the next week or two with other query / distributed systems folks to make a decision on this. |
| Comment by Scott Hernandez (Inactive) [ 26/Apr/16 ] |
|
Would this setting be part of the collection creation options? Or applied after the _id index is built? Will it allow rebuilding the _id index with a new collation, or just setting it once? Replication will require some extra code to handle this, as the cloner and datareplicator use the default _id index spec right now, which is not collation aware, and a static constant. |
| Comment by J Rassi [ 25/Apr/16 ] |
|
This ticket is currently serving as a placeholder for figuring out whether there are any negative implications on the replication or sharding subsystems of allowing the _id index to have a If we decide to proceed with collation support for the _id index, we may or may not want to expose a mechanism for directly setting a collation on the _id index (separate from the mechanism of setting the default collation for a collection). |