I’m trying to understand how the Event Handling works with respect to historical changes.
If I set up a monitor for changes, will I only get changes that occur after the subscription or all historical changes?
If only new changes, then what is the recommended pattern for getting changes that occurred before Event Handler started?
Welcome to the forum @Jason_Whetton!
Changes are for updates that occur after you have subscribed.
Past events will already have been applied to the objects you fetch. Can you provide more detail on your use case?
Regards,
Stennie
Thanks for the response.
Sure, I can describe the use case and perhaps you can advise if my solution is reasonable. I’m new to Realm so it could be that I’m approaching from the wrong angle.
I’m building an inventory management app that retrieves a product catalog and allows users to scan updates (place orders, price changes etc).
The product catalog is a single realm and that works just fine.
The changes by the user are created in a private realm for each user (~/commands).
I was intending to create a handler on the server that would see all changes in any users command realm and process them and update the status. For this to work though, I’d need to also be able to query across these realms in order to fetch any changes that existed before I subscribed (either that or open each realm individually but that feels really awkward.
An alternative solution is to simply put all commands in a single realm for all users (/commands) and add the user id as a property. This way I could do a query for all unhandled commands directly after subscribing. There is an example on github that watches changes for settings from all users (~/settings), so I assumed this was a preferred pattern (segregating user data) but the example doesn’t consider changes that occur when the event handler process is offline.
This is a classic problem with event handling and usually solved with a delta query placed directly after subscribing that is then merged with any notifications received so far.