It isn’t absolutely necessary, as I said before. It has felt convenient, and felt that it could reduce some queries and also some code in the way I have been doing it this far.
Maybe it wasn’t really clear in my original question, or hasn’t been clearly stated in later time, but I don’t try to find document which has empty object in array. Update is going to be for one specific document, which _id
is known. So those examples @Justin gave, are unnecessary, or wouldn’t be used like that.
My document design comes from thought, that document has certain number of badges, which these objects represent. In application empty objects are rendered empty, and when they get content, they automatically render that content. I was thinking that I would have something like count
, and first print outline, and then fill that with how many badges there is, but it felt unnecessary to store extra information to different field, and operate that, when structure of document itself already provides needed information.
I have also been thinking grouping these badges, and having extra variables for how they are wanted to be grouped felt really difficult. But thought now is that I can create multi dimensional array, which holds objects as they are planned to be rendered, and document structure itself then is used for rendering decisions.
And why it goes like that? Because there could be different layouts in documents. Some could be simple having 10 badges, that are dumbed as is. Others could have like 20 badges, but they are wanted to be grouped in four groups, each holding five badges. Or there could be document which has grouping where first row has only three badges, second one four, third one five… or something other funky groupings.
So, to get those funky groupings work, I came up that empty objects can show what is desired layout. At least currently it feels easier to start thinking how to render those, than having some other structure storing layout information.
And this query I was trying to figure out, was query to add one new badge to specific one document. I was thinking of just manipulating arrayOfObjects
in nodejs code, and then push whole array replacing previous, but it felt wrong, as it would potentially change layout. So wanted to have update to target first empty object in that document, so structure remains always unaltered, and there shouldn’t potentially be race conditions if there would be multiple update operations directed to same document ~same time. This way update succees, if there is empty object, or should fail if there isn’t empty one anymore when MongoDB starts doing update (or well, not fail, but not update anything, which I can then detect in nodejs code, and work around that accordingly).
Of course, I am open for ideas, and curious to hear am I creating something that will shoot me in the leg in long run. Does my explanation give more insight of my design/thought process @Justin & @Robert_Cochran? Any comments or doubts?