Hi folks, we have a collection of Pages, and we want to capture changes made to each page. Our system is not yet ready for a full CQRS solution, but we wanted to keep a historical track of changes for each page.
Every time a document changes (any of its properties) we want to save a copy of the current version. However there’s two approaches for that:
We store each Page document as it is with some added metadata, and we would have N entries per each page
We store one top level Page, and inside we have an array of change log where each entry would be a version.
This data would mostly be used for audit, and a restore if needed, from a collection performance perspective does one approach is better than the other? Each page is about 600 bytes in size, there are about 500k pages, and we should probably have about 5-6 revisions for each page.
Hello @Vinicius_Carvalho
I’d suggest to move all older revisions to a second collection. A document from the “revisions collection” references to its “top level” page document in a “top level collection”. Every document in the revisions collection gets a version. In other words you apply the document version pattern. By using a second collection you keep the top level collection small (the less data you work on the faster you are)… Retrieving a/the versions of a single page will be a specific read. Indexing will be a little bit use case dependent.
Regards,
Michael
Thanks @michael_hoeller That is exactly what I was looking for, I already have a PageRevision collection, the recent page version lives on the Pages collection, upon any updates I copy the old revision to the PageRevisions. The only concern I had is whether I’d keep one single item, with several revisions inside, or one document per revision. The good thing I believe the nested model would bring is that I could just use the same objectId as key for both collections. But I can always use the original page id as an index on the revisions I guess.