2015-01-27 12:41 GMT+04:00 Chris Adams <[email protected]>: > Hi Renato, > > On Sat, Jan 24, 2015 at 5:51 AM, Renato Araujo <[email protected]> wrote: > >> Hi Cris, >> >> >> >> On Mon, Jan 19, 2015 at 10:17 PM, Chris Adams <[email protected] >> > wrote: >> >>> QContactType::TypeGroup is meant to represent a group of entities with >>> shared contact details (eg, a local football club might have a mailing-list >>> email address, a clubhouse phone number, etc). Individual contacts can >>> have membership in groups (so various friends can be members of the >>> football club group). I don't think that overloading TypeGroup with >>> aggregation semantics is a great idea, personally. >>> >> >> Thanks for the clarification. I was confuse about the >> QContactType::TypeGroup type, but now I understand how this should be >> implemented. >> >> >> >>> >>> We had a discussion a while ago (I cannot remember where, and a quick >>> grep through QTBUG-31824 failed me) about adding a new >>> QContactType::TypeFacet (to match stdlib nomenclature) or >>> QContactType::TypeConstituent where contacts of those types represent >>> "service- or sync-endpoint-specific contact instances which are aggregated >>> into a 'full' contact". The "full" contact would be a >>> QContactType::TypeContact contact, and it would have >>> QContactRelationship::Aggregates relationships with the Facet/Constituent >>> contacts. >>> >> >> As Matthew mentioned this was already integrated to the mainline. >> >> About the relationships, what I understand now is that (please correct me >> if I am wrong): the Main Contact should contain all the details from other >> contacts, and if I want to have more information (let say that I want to >> know where these details came from), I can use "QContact::relationships()" >> method it will return a list of relationships where I can find the id of >> the others contacts, but these contacts will be of the type >> "QContactType::TypeFacet". >> > > Correct - the Aggregates relationships will tell you which Facet contacts > are aggregated by the main Contact. > > Note that the details themselves have a detailUri field - this is > currently a freeform field, but can be composed of a contactId and a > detailId. So, the details in the main/aggregate contact can "point back" > to the specific contact and detail from which they originally came. >
I, personally, don't like this detailUri concept. In my opinion, we should not provide such kind of info to the user's side - the only one who really needs to know (and track) the detail's origin is a respective backend that did the aggregation, so I'd treat detailUri as a backend's implementation detail. > > >> >> But lets say that I have two normal contacts one from my "local" address >> book and another from my google "address-book" (both contacts contains >> (phone number, email, address, etc) and I want to merge both contacts. Is >> this case should I change the google contact to TypeFacet and merge all >> details into the local contact? >> > > I guess it depends on what you mean by "merge". > > If you want to retain the information about their provenance, and merely > provide a single unified contact for presentation to users, then I would > simply ensure that every contact from an original data source (eg, a sync > source, or entry by the user via UI) is stored as a Facet contact, and that > every Facet contact is linked to exactly one main Contact. In this case, a > phonebook style application would only ever show full Contact contacts, not > Facet contacts (as that would result in duplicates with partial data being > shown). This style of "merge" is really just "linkage", and allows you to > store data from every source separately, maintaining provenance for every > detail. This is what we did in nemomobile qtcontacts-sqlite. (E.G., the > google-addressbook-contact is a Facet, and the local-addressbook-contact is > a Facet, and they are both linked to a Main Contact which aggregates their > details). > > The other alternative, which you describe, is more destructive, so I > personally prefer the previous alternative over an actual merge operation - > but in some cases this is preferable (eg, if syncing from another device > via Bluetooth, for example). > > >> >> >> >>> >>> Then it comes back to what Konstantin suggests: each Facet/Constituent >>> belongs to the particular addressbook (eg, the OwnCloud addressbook, the >>> Fruux addressbook etc) and the Aggregate/Full contact belongs to the >>> FullContacts addressbook. If the user edits the contact on the device, you >>> generate a "local" Facet/Constituent which is also linked into the >>> aggregate. The aggregate can be regenerated on every write, or on every >>> read, depending on the desired performance characteristics for the device / >>> which trade-offs are preferred. >>> >> >> In fact this this looks like a good solution, and If I want, I can use >> the "QContactCollection:extendedMetaData()" method to retrieve a list of >> collections aggregate on this contact >> > > If I understand you correctly, are you saying that you could store the ids > of all collections which contain any Facet contact which is aggregated by a > Contact in the Main/FullContacts collection, in extendedMetaData() fields > of the Main/FullContacts collection? I guess you could, yes. Out of > interest, why is this useful? Generally, I think that would only be useful > on a per-contact basis (eg, so you can show that a given Contact > contains/aggregates data from some specific set of Facet contacts, eg, > Google, OwnCloud, etc) but perhaps I'm missing something? > > >> >> >> >>> >>> Note that this is the way we do it in nemomobile's qtcontacts-sqlite >>> engine, however we use rather artificial separations based on synctarget >>> (string) filtering, rather than Addressbook collections (we'd definitely >>> prefer Addressbook collections, going forward). >>> >> >> I went forward with the implementation, and I have already a MR[1] ready >> for review. Please take a look when you have time: >> >> >> [1] https://codereview.qt-project.org/#/c/104026/ >> > > Fantastic, thanks very much. I haven't had a chance to review it yet, but > Matt and I will take a look sometime this week. > > Kind regards, > Chris. > > > >> >> Thanks >> Renato >> > > Regards, Konstantin
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
