[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