[Kde-pim] Changing UID of a newly created Akonadi::Item

[Kevin Krammer]

On Thursday, 2011-11-24, Dan Vratil wrote:
> On Wednesday, November 23, 2011 13:25:15 Kevin Krammer wrote:

> > Try running Akonadiconsole when doing that and enable the debugger (tab
> > Debugger). It shows the actual data transfer between Akonadiserver and
> > its clients, so you could check if the new payload is sent correctly.
> 
> After accepting the Incidence editor, this appears in the debugger (note
> the generic UID):
> 
> 24 UID FETCH 23014 FULLPAYLOAD CACHEONLY EXTERNALPAYLOAD (UID REMOTEID
> REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME)
> * 23014 FETCH (UID 23014 REV 0 REMOTEID "" MIMETYPE "application/x-
> vnd.akonadi.calendar.event" COLLECTIONID 126 SIZE 416 DATETIME "23-Nov-2011
> 23:08:40 +0000" FLAGS () PLD:RFC822 {416} BEGIN:VCALENDAR PRODID:-//K
> Desktop Environment//NONSGML libkcal 3.2//EN VERSION:2.0 BEGIN:VEVENT
> CREATED:20111123T230840Z ORGANIZER;CN="Dan Vratil":MAILTO:dan at progdan.cz
> DTSTAMP:20111123T230822Z UID:9e98f5ae-d00b-40ba-b292-d68df47dd6d8 LAST-
> MODIFIED:20111123T230822Z SUMMARY:A new bla test LOCATION:somewhere
> DTSTART;VALUE=DATE:20111125 DTEND;VALUE=DATE:20111126 TRANSP:OPAQUE
> END:VEVENT END:VCALENDAR)
> 24 OK UID FETCH completed

That looks ok.

> (I'm wondering how anyone can "FETCH" an item that has not yet been
> actually added to Akonadi....?).

It has been added by the creator of the event, i.e. the application displaying 
the incidence editor.

> This appears after reply from Google is received, after calling
> changeComitted();
> 
> 24 UID STORE 23011 NOREV (REMOTEID "k7vr32iij11qiebaofogf789h8"
> REMOTEREVISION "\"F0oNRQFDfCp7JGA6WhJW\"" DIRTY false)
> 
> Despite the fact I assigned a new payload, it only sees changes in remoteID
> and remoteRevision, the payload change is simply ignored.

Right. I checked the ResourceBase code and it explicitly ignores payload.
What you could try is to not set a payload on the item but call 
item.clearPayload().
I am not sure if it works when payload changes are ignored but usually it 
would tell  Akonadi to forget any cached payload and thus make it ask the 
resource the next time anyone fetches the item.

Alternatively you can call changeComitted() and then use a ItemModifyJob to 
change the payload.

> But without any result, the payload UID is not changed. So I'm beginning to
> wonder - am I even allowed to change payload of newly created Akonadi item?

It seems not in the changeComitted() call.

> You can see the current sources (without payload changing) here:
> 
> http://quickgit.kde.org/?p=akonadi-
> google.git&a=blob&f=calendar/calendarresource.cpp
> 
> There are the two main slots: itemAdded() (called from Akonadi) and
> eventCreated() (reply from Google).
> 
> > > So my question is, what am I doing wrong and how can I overwrite the
> > > Akonadi's generic UID?
> > > 
> > > I'm sometimes getting similar warnings in .xsession-errors:
> > > 
> > > plasma-desktop(5193)/plasma: Ignoring item. item.id() = 1879 ; cached
> > > id = 0 ; item uid = "MDg5MjIwMDc5Mzg2MDE1MDg3NzY6MDoxODUyMjExNjE0" ;
> > > calendar = "" ; existed in cache = false ; storageCollection.id() = 24
> > > ;
> > > parentCollection.id() = 24 ; hasParent = false ; knowParent = false
> > > 
> > >  plasma-desktop(5193)/plasma: Possible cause is that the resource isn't
> > > 
> > > explicitly setting an uid ( and a random one is generated )
> > > 
> > > This makes me assume  that I am supposed to replace the generic ID by
> > > my own, yet I don't know how :)
> > 
> > Even a generic ID in the payload should be fine for whatever is looking
> > at the payload.
> > Usually the application creating an event is setting the UID.
> > Most resources don't need to change the payload at all (they just save
> > and load the data as it is).
> 
> The problem with payload UID is that when user changes the event via Google
> Calendar web interface and then synchronizes the resource, the UID is
> updated as well together with the other informations . And that's not OK,
> I think that UID should remain constant for the lifetime of the event, not
> changed after first synchronization.

But in this case changing the UID in itemAdded() would just do that, no?

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/20111124/b8adb42a/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/