[Kde-pim] Question: Akonadi::TransactionSequence

[Kevin Krammer]

On Tuesday 29 January 2008, Volker Krause wrote:

> I had a quick look at the code, the reason might be that you create those
> jobs without a parent object. Thus they are associated with the default
> session instead of the parent job/transaction sequence, although you called
> addSubjob() manually. This results in two instances feeling responsible to
> manage the job (the top-level session and the parent job), which obviously
> confuses at least one of them.

Yes, I change that before switching to ItemSync and it worked better.

The API of the job classes is not very obvious about this, i.e. the parent 
parameter is just QObject and has a default, so I assumed it just for the 
usual Qt parent/child relationship.

> We probably could add an assert() in addSubjob() to check for this, or just
> make it private since it is called internally already on the parent job.

It is already protected, but it looked like the only possibility to get the 
new sub job into the composite job.
After studying the ItemSync code a bit, I figured out that passing the 
composite as the parent was the actual way to go.

I guess it is just a matter of making the API dox more explicit about this, 
probably already at kdelibs level (KCompositeJob doesn't mention this either)

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: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20080129/bbdf5c36/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/