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

[David Jarvie]

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.

-- 
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100927/e45dac35/attachment.sig>
-------------- next part --------------
_______________________________________________
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/