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

[David Jarvie]

On Mon, September 27, 2010 11:10 pm, David Jarvie wrote:
> On Monday 27 September 2010 16:57:13 David Jarvie wrote:
>> On Mon, September 27, 2010 4:48 pm, Sérgio Martins wrote:
>> > 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.
>>
>> I implemented a queue in KAlarm before I realised that I was duplicating
>> ETM's jobs. I'm not sure whether I still have the code - I could look
>> for
>> it tonight if you want - but it was fairly simple.
>
> It turns out that the job queuing code for KAlarm is in SVN (trunk). It's
> in kalarm/akonadimodel.{h,cpp} - see AkonadiModel::queueItemModifyJob()
> and AkonadiModel::itemJobDone(). The calls to queueItemModifyJob() are
> commented out, so that the queuing mechanism isn't actually used
> currently.

Any update on this? Update conflicts are causing real problems for KAlarm
(see also the recent thread "Akonadi conflict problem - possibly
EntityTreeModel issue?"), so much so that it will prevent the Akonadi port
of KAlarm being released in KDE 4.6 unless they can be fixed one way or
another. I'm willing to work on this if necessary to help get it done.

-- 
David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm

_______________________________________________
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/