[Kde-pim] SEGV reading Akonadi::Attribute from retrieveItem

[Daniel Vrátil]

On Thursday 29 of May 2014 19:03:49 Jesús Pérez wrote:
> > > bool testResource::retrieveItem( const Akonadi::Item &item, const
> > > QSet<QByteArray> &parts )
> > > {
> > > 
> > >   TestAttribute *attr =
> > >   item.parentCollection().attribute<TestAttribute>(); // NULL pointer
> > >   QByteArray attr_value = attr->serialized(); // SEGV
> > 
> > If you need to have access to item's parent collection attributes, you
> > need to retrieve the collection manually.
> 
> So I need to use a CollectionFetchJob?

Yes. The good things is that you don't need to return the item directly in 
retrieveItem() method, but you can do it asynchronously, so you can have 
something like

testResource::retrieveItem(const Akonadi::Item &item, const QSet<QByteArray> 
&parts) {
	CollectionFetchJob *fetchJob = new 
CollectionFetchJob(Collection(item.parentCollectionId()));
       fetchJob->setProperty("Item", QVariant::fromValue(item));
       fetchJob->setProperty("Parts", QVariant::fromValue(parts));
	connect(fetchJob, SIGNAL(finishedKJob*)).
                         this, SLOT(onRetrieveItemCollectionFetched(KJob*)));
}

testResource::onRetrieveItemCollectionFetched(KJob *job)
{
	// TODO: Check for errors
	CollectionFetchJob *fetch = qobject_cat<CollectionFetchJob*>(job);
	// TODO: Check !fetch->collections.isEmpty();
	Collection collection = fetch->collections().first();
	Item item = fetch->property("Item").value<Item>();
	const QSet<QByteArray> parts = fetch-
>property("Parts").value<QSet<QByteArray>>();
	...
	...
	// Set the requested payload
	item.setPayload<...>(....);
	...

	// Return the item to Akonadi
	itemRetrieved(item);
}

> 
> > For performance
> > reasons, it's possible to specify what all parts of Item (or Collection)
> > you want to fetch from Akonadi server, I think attributes for items are
> > disabled by default.
> 
> And how can I specify that?
> I though that changeRecorder()->fetchCollection(true) or
> changeRecorder()->setCollectionFetchScope() may help, but they don't.

This actually works, but it won't affect scope of 
Akonadi::Item::parentCollection() - this will always only return Collection 
with just ID set (maybe remoteID).

> Also, according to documentation
> <http://api.kde.org/4.x-api/kdepimlibs-apidocs/akonadi/html/classAkonadi_1_1
> CollectionFetchScope.html#details>:
>
> "Note that CollectionFetchScope always includes fetching collection
> attributes".

Sorry for confusion, CollectionFetchJob indeed always returns attributes.

> 
> I've been researching this for hours and found no solution yet. So,
> unless someone can help me with this, I think I'm gonna store a
> collection id <-> attribute pair value in KConfig so I can read it
> from retrieveItem. Any alternative?
> _______________________________________________
> 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/

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140602/ac22dac5/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/