[Interest] Models and aborting structural changes

[Jonathan Purol]

> I understand your problem. I've not been in your situation, but how about
> 
> - Change server to emit before and after events, plus a cancel event.
> 
> - Upon receiving a before event, call beginInsertRows,
> 
> - Upon receiving an after event, call endInsertRows,
> 
> - Upon receiving a cancel event, call endInsertRows, then call
> beginRemoveRows, remove the cancelled rows, then call endRemoveRows.
> 
> Could that work? I don't think the models would ever show the cancelled
> data, as control never returned to the event loop during the dance in
> the last step.


I have thought about that and believe that in theory it could work
although it would require some testing.
What should definitely work is to call `begin/endResetModel` in case an
error occurs, though that has obvious drawbacks as well. I'd have to
give it a test run. It does seem like a very hacky solution however.
I've spoken with my partners and for now we'll just go with a cache that
duplicates all necessary data - from what I understand we only really
have to duplicate structural information, since the normal "data
changes" don't require the begin-end system (i.e. `emit dataChanged`).

> Thinking a bit more (and I'm no expert), if I understand your setup
> correctly, I still think there's a race that could confuse your views.
> 
> If I understand you right, your model always reports "live" data from
> the server, which I presume means your data(..) returns data fetched
> from the server.
> 
> If so, then I think this scenario could happen (?):
> 
> 1. View requests some data at index X, and gets back data Y.
> 2. Something happens on the server so the data changes.
> 3. The server sends out a change event.
> 4. View again requests some data at index X, but gets back data Z (!).
> 5. The change event arrives at your application.
> ...
> 
> This is a situation in which the data returned at some index changes
> from the POV of the view, with no beginInsertRows/endInsertRows in
> between, which I think is a breach of the Qt model/view contract.
> 
> I may be wrong though, so maybe someone more knowledgeable can step in
> an confirm/deny.

Yeah this would definitely break the contract. Furthermore - I believe
Qt wouldn't even poll for any information about index X if it hasn't
been established that index X exists yet (either by a remove, insert, or
move command). Anything else would seem like a false implementation of
what I expect the view-classes to do.

I genuinely believe that the `abort*` functions are just... missing - it
seems like such an inherent feature to me. Perhaps the complexity of
implementing it was considered too large to be worth the hassle. In the
forums people say "just verify everything beforehand" - but not every
situation warrants that.


Thank you for your time and effort! If I try out the "just call the
reverse if it fails" and it works I'll let you know!

cheers,
Jonathan Purol