Interesting use case - using this package to restore database state after over-keen clients have messed it up a bit. I wish I could say “Yes. No problem.” (I too have a demo site that I want people to play with, but then be able to clean up afterwards.) Unfortunately, that’s not the case.
The way the package maintains a reasonable semblance of database integrity is by not allowing an undo in certain situations - e.g. a document is inserted in one transaction and updated in another transaction - the first transaction cannot now be undone (as then the document would be removed from the database, meaning the second transaction couldn’t be undone). This means that certain transactions have ‘expired’ and are no longer undo or redo-able.
There are certainly be better ways to manage this and, in response to your suggestion, I’ve begun thinking about how this might be done, but I can’t promise big changes anytime soon.
With regard to scaling, I have to give that perennially annoying answer – it depends on the app. If you don’t subscribe to the transactions collection, it’s fairly low impact.
However, if you use
babrahams:undo-redo for an easy undo/redo widget, you’ll have a unique subscription to the
transactions collection per user, and because this collection gets belted with writes on every transaction, the oplog gets a lot of activity, which then puts massive burn on the cpu as the mergebox tries to update the subscriptions for each of the individual users. For apps with a heavy write load and a lot of connected users, the
babrahams:undo-redo package is going to need to use something a bit smarter than the current pub-sub model. Not too hard to implement, I think, just not implemented yet.