On 3 June 2020 at 12:52:01, Jonathan Purol ([email protected]) wrote: > why not cache the bulk changes received from server, and only after > observing a complete set of changes you begin updating the Qt model? > i.e. you should first receive a complete bulk of changes from server > like <“before”, “change item i1”, “change item i2”, …, “after”> and only > at that point you can start changing the Qt model by calling > beginInsertRows() followed by other model changing methods and then > endInsertRows().
It's less about knowing when a change is complete - ideally the UI should not care if multiple changes are adhering to some common denominator or not. The issue for us is that the underlying data is already updated when the change notification comes through, in which case `beginInsertRows` would be called too late, since it has to be called *before* the underlying data has changed. So, is the issue that the client might attempt to modify some data which is already old (because there is some change coming from the server to the UI, which hasn’t reached the UI yet)? In that case I’d use optimistic locking, i.e. assign a version number to the data. Upon each data change, version is incremented. If the client submits an edit whose version number is less than the actual version number (which means the client hasn’t observed all changes yet) simply discard that edit. Cheers, Federico Ferri
_______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
