Am Dienstag, den 07.06.2011, 09:19 +0200 schrieb michael.godd...@nokia.com: > Hello, > > [snip] > > > > > Hmm, I wonder whether app developers are aware of this. It implies > > > > that > > > > passing QContactId between processes is not correct, because these > > > > IDs > > > > are only valid inside the process. > > That would be unfortunate, particularly also with the QContactAction stuff - > the actions might be in another process. > > > > > Connie, how are contacts references inside the MeeGo UX (for things > > > > like > > > > "show contact XYZ")? QContactId or QContactGuid? > > > > > > Hmm that would still be correct I guess, but you'd have to check with > > > the mobility developers... I wouldn't expect the DB to change the ids > > > for one same contact from one program to another, > > > > But that's the same situation as above: if QContactLocalId are only > > valid during the runtime of a program, or even only while it has the DB > > open, then there's no guarantee that QContactLocalId 1 in program A > > refers to the same contact in program B. > > > > Michael, can you clarify what the lifetime of QContactLocalId is meant > > to be? The documentation is silent on that matter, as far as I know. > > The intent is for the localids to be persistent and stable.
"Persistent and stable" in which sense? E.g. for the tracker backend we use tracker's row id as local contact id. This id remains stable during lifetime of tracker db, but if it needs to be rebuilt, e.g. when restoring a backup the row ids will change. Changing this behavior would cause a significant performance penalty for the tracker backend. So from my POV indeed the GUID should be used for creating a long term contact reference. To speed up things one could store both local id and GUID, fetch by local id and only fall back to GUID mode when fetched GUID doesn't match expected GUID. But that would be an additional optimization. If you don't like that approach, how about introducing explicit long-term references? The default implementation would just map them to QContactId, backends that don't have ever lasting local ids would provide their own mechanism. Ciao, Mathias -- Mathias Hasselmann <math...@openismus.com> http://openismus.com/ _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
