[Kde-pim] Akonadi collection attribute not being fetched correctly

[Kevin Krammer]

On Friday, 2010-09-10, David Jarvie wrote:
> On Friday 10 September 2010 07:23:27 Kevin Krammer wrote:
> > On Friday, 2010-09-10, David Jarvie wrote:
> > > Sometimes calling Collection::attribute<T>() does not return the
> > > correct value of the attribute. I find that sometimes when an
> > > attribute is updated, and a CollectionModifyJob is then used to update
> > > the value in the Akonadi database, the database is updated
> > > successfully (as shown in AkonadiConsole) and the correct, new, value
> > > of the attribute is returned if it is accessed in the
> > > CollectionModifyJob result slot. But the next time the attribute is
> > > accessed in a different part of the program, the old value of the
> > > attribute is returned.
> > 
> > Maybe that other part of the code is still working with an older copy of
> > the collection and thus its attribute.
> > E.g. stored as a member and neither updated after the collection modify
> > nor through connection to a monitor signal.
> > 
> > > Is some special action needed to ensure that a specific Collection
> > > instance returns the up to date value of one of its Attributes?
> > 
> > No. As long as the collection is up to date, its attributes should be as
> > well.
> 
> So how can the collection be updated? Is it necessary to construct a new
> instance with the same ID?

A collection, as in an instance of Akonadi::Collection, is just an object 
holding data in its member variables.
A long as no "setter" is called all members keep the values they have.

So if a collection instance is stored somewhere, e.g. as a member of another 
class, this member will always return the data the collection instance was 
carrying at the time of assignment.

Let say you have

class MyClass {
public:
  void update();

private:
  Collection mCollection;
};


void MyClass::update()
{
  Collection collection = mCollection;
  // collection and mCollection hold same values

  collection.attribute<MyAttribute>->setFoo( true );
  // collection and mCollection have different foo value in MyAttribute

  CollectionModifyJob *job = new CollectionModifyJob( collection );
  job->exec();
  // Akonadi now also has new foo value, mCollection is still untouched
  
  mCollection = job->collection(); // mCollection updated as well
}

Another option is to have an instance of Akonadi::Monitor and connect to its 
collection signals and update mCollection in such a slot if the signal's 
collection is mCollection ("is" as in operator==() returns true).

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/20100910/cc805801/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/