[SERVER-38370] Creating a compound unique index with _id is successful, even when _id is not the shard key Created: 03/Dec/18 Updated: 06/Dec/22 Resolved: 03/Jan/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Alyson Cabral (Inactive) | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query
|
| Operating System: | ALL |
| Participants: |
| Description |
|
where test.bar unique: true
|
| Comments |
| Comment by Craig Homa [ 03/Jan/19 ] | |
|
Closing as won't fix, please see the comment above. | |
| Comment by Asya Kamsky [ 02/Jan/19 ] | |
|
Currently we allow (in fact require) that there is a (unique) index on {_id:1}. Any additional index which has _id as the first field is (for lack of better phrase) just as "unique" as the required/expected _id index, so it seems harmless to allow it. More importantly, disallowing it could be considerable amount of work as we would have to figure out how to deal with existing indexes like this that would no longer be allowed.
| |
| Comment by Alyson Cabral (Inactive) [ 28/Dec/18 ] | |
|
I believe the current behavior is inconsistent with not allowing unique indexes on arbitrary fields. If we think there is value in allowing unique _id indexes then we should allow unique indexes on any field. I, personally, do not think unique indexes should be allowed in any case on non-shard key fields until we expand support to make the guarantee meaningful. | |
| Comment by Asya Kamsky [ 21/Dec/18 ] | |
|
alyson.cabral is there a problem with this being allowed? | |
| Comment by Asya Kamsky [ 17/Dec/18 ] | |
|
This comment explains: | |
| Comment by Asya Kamsky [ 17/Dec/18 ] | |
|
Actually I think the issue was introduced as | |
| Comment by Asya Kamsky [ 17/Dec/18 ] | |
|
Yep, this occurred whether the shard key is in the index or not. It occurs because of this line of code:
we then return true. So if the first element is _id field we return ok. We used to do this test like string("_id") == uniqueIndexPattern.firstElementFieldName() but of course that's the same idea. I think it's been this way since Greg added the unique index prohibition in https://github.com/mongodb/mongo/commit/3c707bd5a995776d70cc740a0c7220c5986aacde for 2.5.5 Anyway, the check probably should not have been there. | |
| Comment by Craig Homa [ 13/Dec/18 ] | |
|
We will investigate if this also occurs w/o the shard key being included. |