Hi Cris,
On Mon, Jan 19, 2015 at 10:17 PM, Chris Adams <chris.ad...@qinetic.com.au> 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". 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? > > 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 > > 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/ Thanks Renato
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development