[Kde-pim] Re: EntityTreeModel doesn't handle setData(Item) calls in quick succession

[Sérgio Martins]

On Mon, Sep 27, 2010 at 12:11 PM, Stephen Kelly <steveire at gmail.com> wrote:
> Stephen Kelly wrote:
>
>> Correct. This is something I've been meaning to find a solution for for a
>> while. I'd like it to be solved on a Session level, or at least on a
>> generic level. Volker said there was something in KOrg for this as a
>> starting point?
>
> Sergio do you know something about this? I think you wrote the code I
> mentioned here. Can it be made generic and put into session?

I had this problem in korg:

1. modifyJob1 for itemA is created (and revision is incremented internally).

2. User does more changes on the same item.

3. KOrg knows modifyJob1 didn't finish yet, so it keeps¹ the change
and will only trigger a 2nd modifyJob when the first ends.

4. modifyJob1 finishes and KOrg fires modifyJob2.

Problem: The item sent in modifyJob2 still has the old revision,
because the user was too fast.

Solution: Do an item2.setRevision( item1.revision() ) before fireing
modifyJob2. This "hack" doesn't break conflict resolution because
we're certain that the revision we're setting came from us. If an
external program changes the item, we still get the conflict dialog.


Notes:
¹ - It doesn't use a queue to keep changes. If change3 appears, only
change3 is kept, change2 is discarded, and when modifyJob1 finishes,
change3 is sent.


Steve, I don't think there's much to be reused, just used a variable
to put the latest change on hold, and increment the revision safely.




Cheers,
Sérgio
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/