That’s a major drawback.
My goal was to avoid creating an index. 8-(
The above was surprising but would not have been a problem except may be when doing manual query while debugging. I am planning to have all object creation and all queries to be done via an well defined API. But I play a little bit and I found that the following works and it is usually how I do manual queries.
> db.foo.find({ "_id.b" : 1 , "_id.a" : 1 } )
{ "_id" : { "a" : 1, "b" : 1 } }
> db.foo.find({ "_id.a" : 1 , "_id.b" : 1 } )
{ "_id" : { "a" : 1, "b" : 1 } }
I like strings too but wanted to avoid sub-string search or regex.
Most of my use cases are complete matches on major/minor but one is to use the change stream on major to monitor the creating and deletion of minor.
Actually, major/minor was may be over simplifying. It is more of a parent/child thing. Like may be domain names, where major would be like .com, .edu and minor would be subdomain like mongodb or google. File paths are also good example. So _id would be like
{ _id : { parent : com , name : mongodb } }
{ _id : { parent : com , name : google } }
{ _id : { parent : null , name : com } }
{ _id : { parent : mongodb.com : community } }
or
{ _id : { parent : null , name : / } }
{ _id : { parent : / , name : etc } }
{ _id : { parent : /etc , name : systemd } }
I think I could live with
{ _id : mongodb.com }
{ _id : google.com }
{ _id : com }
{ _id : developer.mongodb.com/community/forums }
or
{ _id : / }
{ _id : /etc }
{ _id : /etc/systemd }
Which use less memory anyway. There is also a minor drawback with Compass as by default object are not expanded so when I am looking for a specific document, I need to do an exact search or click on each document to expand the _id. I probably can tolerate a little bit of duplication by having a parent field for the few documents implicated in the use cases where parent is needed, because most will not.
And finally
yes just like I always do.
{
"conclusion" : "string I will go" ,
"thanks" : "all"
}