[Kde-pim] Akonadi attribute oddities
Stephen Kelly
steveire at gmail.com
Tue Dec 22 14:11:57 GMT 2009
David Jarvie wrote:
> I'm puzzled by some code in EntityTreeModel which manipulates Attributes.
> In setData(), it fetches the collection's Attribute, sets a value in it,
> and then calls collection.addAttribute() to update it in the collection.
>
> Why is the addAttribute() call needed? AFAICS, Entity::attribute() returns
> a pointer to the actual Attribute, not a pointer to a copy, so that
> changing the Attribute returned by it will change the value attached to
> the Entity. The addAttribute() call seems to be superfluous.
Indeed. I removed those now.
>
> In addition to that, AFAICS, addAttribute() called with the existing
> Attribute as a parameter will first delete any existing Attribute (which
> happens to be the same one as in the parameter), and then add the (now
> deleted) Attribute back into the Entity. So addAttribute() should first
> check whether the supplied Attribute is the same as the one it already
> holds, and if so, do nothing. Or am I missing something?
>
Yes, I don't see why the call to addAttribute wasn't crashing all the time.
The check for setting the current attribute might be a good idea. Care to
write that and a unit test for it?
Thanks for the review and keep it coming. I'll try to get around to adding
more dox about entityData. Generally the ETM tries to do everything it can
in data, and for type-specific stuff, like figuring out what the email
subject or sender, or the addressee name or email address, it delegates to
the subclass. That might not hold water in all cases, but it was the initial
intention. I'll investigate a bit more of what it currently does.
All the best,
Steve.
_______________________________________________
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/
More information about the kde-pim
mailing list