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. I think that was met with the initial set of backends (except for the case that you've discovered with the hashing of an EDS id, assuming that the EDS id is stable enough). I'm not sure why we didn't document that though :/ QContactGuid is certainly harder to use to look up a contact/contacts. > > but I wouldn't expect > > the DB to keep local ids valid from one DB session to another (for > > example with Tracker, we sometimes have to rebuild the DB if the > schema > > changed → IDs can be invalidated). Also, I'm not totally sure if > > QContactGuid is mandatory, if not it makes things even more tricky :/ > > I don't know either. Yes, tricky :/ I think the "rebuild tracker db so trackerid changes" case is also kind of like a backup/restore scenario. Perhaps the sync software (or whoever) really does need to do a slow sync/rebuild in that case. Applications probably do need to care about that (I guess a dataChanged() signal is one rather crude way of saying that "things really changed"). Cheers, MichaelG _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
