GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
Remove opData object in MongoDB ops, flattening the other data into t…
…he root of the document. Closes #160
@zamfi happy with this?
Actually the loop doesn't need to create that result array. The docs array is already there and all that needs to be done is to remove the _id on all the docs.
In fact, I don't think there's an issue with the _id being in the returned doc at all (I might be wrong). How about just returning the docs array?
I did it that way just to make backwards compatibility simple. I suppose it could iterate over docs and remove opData if it exists. Or, of course, we could write a migration script.
A migration script might actually be the best, since even if you don't run it the future operations are fine and the snapshots are right where they're supposed to be. There won't be a performance hit on read then.
That sounds sensible. What about ops that haven't been snapshotted yet, though?
Perhaps we could do two steps: first, release it with backwards compatibility and the small performance hit alongside a migration script. Then, in the next version, we remove backwards compatibility.
Migration to flatten opData object in existing MongoDB documents
There we go!