[Kde-pim] Problem with bulk fetching of items with 4.8

[Kevin Krammer]

On Friday, 2012-01-27, Shaheed Haque wrote:
> Hi Kevin,
> 
> See below...
> 
> 2012/1/26 Kevin Krammer <kevin.krammer at gmx.at>
> 
> > Hi Shaheed,
> > 
> > On Thursday, 2012-01-26, Shaheed Haque wrote:
> > > Hi,
> > > 
> > > I just upgraded to kde 4.8 etc., and now I'm running into a problem
> > > with the Exchange Contacts resource (the one in the playground).
> > > Basically, the problem is that I am trying to retrieve ~467,000
> > > contacts, and so rather than the normal scheme of crreating "skeleton"
> > > item in retrieveItems(), and then fetching the full item in
> > > retrieveItem(), I've been creating the full item (i.e. with a payload)
> > > by kicking off a scheduleCustomTask from retrieveItems().
> > 
> > While I don't know what might have changed in the Akonadi libs that
> > causes this (Volker might), I'd like to ask what you need the custom
> > task for.
> > 
> > The item retrieval is not bound to the life time of the retrieveItems()
> > call, so you could start any operation right in there and just call
> > itemRetrievalDone() whenever this (potentially asynchronous) operation is
> > done.
> 
> That's interesting. I had assumed that retrieveItems() was supposed to
> finish "quickly", so I'm doing something like this:

Yeah, could probably need a more explicit documentation. The resource can stay 
within a task's execution context if it wants to, but of course any other 
tasks will be queued in the meanwhile.

> retrieveItems()
> {
>     ...
>     scheduleCustomTask("retrieveGALItems")
>     cancelTask()

Ah. Here you are cancelling the retrieveItems task, basically telling Akonadi 
that you can't currently execute what it is asking for.

Seems prior to 4.8 some internal setup for that task survived and therefore 
hid that you were using them "out of scope".

Now the task's context is cleared correctly and your calls to 
retrieveItemsIncremental try to access stuff that is no longer valid.
We might need some asserts in there to catch that more explicitly.

> }
> 
> retrieveGALItems()
> {
>     ...
>     fetch 300 items from Exchange
>     itemsRetrievedIncremental(items);
>     // go around again.
>     scheduleCustomTask("retrieveGALItems")
> }

Your approach is not bad either, the problem was that you were calling methods 
associated with a certain task outside of that task's context.

For example you could end item retrieval immediately (even with zero items) 
and then use your scheduled custom tasks to add or modify items when they come 
in using respective item jobs.

From any user application's point of view this would look like an empty 
collection being populated later on.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20120127/a3d4b3ff/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/