[Development] QContactLocalId in Qt5

[Mathias Hasselmann]

Am Dienstag, den 01.11.2011, 09:56 +0100 schrieb Robin Burchell:
> Hi Paivi,
> 
> (taking this back to my original thread)
> 
> On Thu, Oct 27, 2011 at 5:08 PM,  <paivi.rajala at nokia.com> wrote:
> > We thought that having an integer QContactLocalId is a bit too restricting.
> > E.g. if you have a uuid as backend contact id (as the case is in JsonDb backend),
> > it's lot simpler to treat it as a string than as an integer. Changing
> > QContactLocalId to QString was the first step in trying to make contact
> > ids a bit more flexible.
> 
> OK. Believe it or not, I agree. I've had to write a UUID-to-integer
> translation in my own personal engine plugin, and for instance I
> believe qtcontacts-eds had to do a uuid fetch request on startup and
> generate a QHash mapping their UUIDs to integers, too.

Well, for qtcontacts-tracker we found a reasonable solution to represent
local ids as integers. Well, but actually we also lost quite some hairs
until we found our solution - by chance, I have to admit: Tracker
exposes the row ids of its internal database. So yes, turning the local
id into something string like would make much of sense.

Playing the devil, what speaks against QVariant? Would give backends
with native numeric contact ids the chance to save a few resources.

> > Another step towards that direction would be to hide the internal format of
> > backend contact id by providing a wrapper class for backend ids. This pattern
> > has been used in Organizer, see
> > http://qt.gitorious.org/qt/qtpim/blobs/master/src/organizer/qorganizeritemengineid.h and
> > http://qt.gitorious.org/qt/qtpim/blobs/master/src/organizer/qorganizeritemid.h.
> 
> This might make sense. Just keep memory constraints in mind. I don't
> know about typical organizer patterns, but often, applications dealing
> with contacts are forced (for various reasons, efficiency, etc) to
> keep a memory representation of a large number of contacts in memory.
> If you're heap allocating IDs (as well as all their details etc) -
> that's another penalty you're going to pay in terms of performance.
> Probably not *that* huge a concern, just make sure to measure first.
> :)

Cannot you explain the idea behind this? I cannot follow right now.

> > About source-compatibility... As a Qt5 AddOn module QtPim has little less restrictions
> > regarding source-compatibility than Essential modules, see e.g.
> > http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Qt5ProductDefinition.
> > While we try not to break source-compatibility if it's not necessary, we
> > also see moving from QtMobility to QtPim as a good opportunity to simplify QtPim
> > APIs a bit and to make some other changes, which might be more difficult later.
> > Some of the changes are already visible in qtpim repository, some are still in the
> > planning phase. We will tell more about the changes and reasoning behind
> > them in the near future.
> 
> OK.
> 
> You should probably also talk to some of the Harmattan contacts guys
> if you haven't already (of which I am one, a few other of which I've
> CC'd). They may have some other ideas on potential changes for
> source-incompatible Qt 5 changes.

We definitely would have benefited from an offical approach for
introducing custom requests:

https://gitorious.org/qtcontacts-tracker/qtcontacts-tracker/blobs/master/src/lib/contactlocalidfetchrequest.h
https://gitorious.org/qtcontacts-tracker/qtcontacts-tracker/blobs/master/src/lib/contactmergerequest.h
https://gitorious.org/qtcontacts-tracker/qtcontacts-tracker/blobs/master/src/lib/unmergeimcontactsrequest.h

The solution we found to work around QtContacts limitations is...
hideous:

https://gitorious.org/qtcontacts-tracker/qtcontacts-tracker/blobs/master/src/engine/engine.cpp#line1794
https://gitorious.org/qtcontacts-tracker/qtcontacts-tracker/blobs/master/src/engine/contactidfetchrequest.cpp#line52

Ciao,
Mathias
-- 
Mathias Hasselmann <mathias at openismus.com>
http://openismus.com/