Using Mongodb oplog for tracking data change history [closed]

Question

I am looking at using MongoDB for an app. I am rather new to MongoDB. I need to track the changes users makes to the system, what was added/changed and when. The oplog appears to contain all the data I need and it seemed to me that persisting a copy of the oplog to a separate uncapped collection would give me all the history I need. It would not need to be quickly retrievable or immediately available.

Is there a problem with this approach? Can anyone suggest a best way to store this data?

Answer 1

The problem with this approach is that it's extremely low-level. It will be excruciatingly annoying to recover this information to a point where it makes sense from an application perspective.

For instance, let's say you're changing the name of a user. Do you use $set or do you replace the user object? From an application point of view, it doesn't matter, but the oplog will look completely different. Also, if you're using the replace, the information contained in the oplog will not contain only the changes, but only the new state. That means that the only way to understand what was really going on is to perform a full replay of all operations (so you have the old and the new state).

Also, the oplog doesn't contain any information on which user performed which operation, unless you're using database users as application users, which I would strongly advise against.

In my opinion, this should be handled by the application. For example, you could use the Unit of Work pattern, but instead of using it only intermittently on the client, you might want to actually serialize the Unit of Work (or some representation of it) to the database. I'm pretty sure there's a name for this pattern, I just can't remember it at this point.