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

[Dan Vratil]

On Thursday, November 24, 2011 10:41:16 Kevin Krammer wrote:
> 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.

Yop, that works :) Thank you very much for help.

> 
> > 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?

Yes, but I change it when the item is created, so at the very beginning of 
it's existence when nobody minds :). Until now the UID changed after user 
modified the event in Google and the resource had fetched the update, which is 
much worse situation.

Thanks again,
Dan

> 
> Cheers,
> Kevin
-- 
---
Dan Vrátil
www.progdan.cz
dan at progdan.cz
Jabber: progdan at jabber.cz

Tento email neobsahuje žádné viry, protože odesílatel nepoužívá
Windows. / This email does not contain any viruses because the sender does not 
use  Windows.
-------------- 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/20111124/7d70fe02/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/