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

[David Jarvie]

On Monday 13 September 2010 07:52:45 Stephen Kelly wrote:
> David Jarvie wrote:
> 
> > When successive calls are made quickly to EntityTreeModel::setData(...,
> > ItemRole, ...) for the same Akonadi Item (and same model index), conflicts
> > occur (the conflict resolve dialog appears). This seems to be because the
> > Item revision number can be the same for two calls if the first
> > ItemModifyJob has not completed when the second setData() is called.
> 
> > 
> > I suspect that it is necessary for EntityTreeModel to implement a queuing
> > system for ItemModifyJob, which waits for one job to complete before the
> > next is created. In the result slot for the job, the Item revision number
> > in the next queued job would need to be updated to the new value before
> > the job is scheduled.
> 
> 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?

I wonder if you have any estimate as to when this might be done. Currently in KAlarm, there are some circumstances where two updates to the same Item in quick succession will always occur, with the resultant resolve conflict. It isn't practical to try to combine the updates to avoid this, since the two updates are dont in unrelated parts of the program, and I don't see any way of using EntityTreeModel::setData() to handle the conflict in the program rather than output the conflict resolve dialog. Also, updating the Item attributes (which is one of the two clashing updates) causes an automatic update without having to call setData().

> > The
> > symptom also occurs when Item attributes are modified (without a call to 
> > setData()).
> 
> This sounds suspicious. Are the attributes updated on the server but not in 
> the model? Is the change recorder monitoring the attributes?

I can't say whether the attributes are updated in the server or model, because the attribute update always clashes with another update. Item attribute changes in the server don't seem to be monitored, although I want them to be - I don't know what setting is needed to enable this.

-- 
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/20100918/2f4d3867/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/