George Niculae wrote: > > --- On Tue, 1/12/10, Arjun Nair <[email protected]> wrote: >> I am going through XX-7304 [1] and I >> noticed that when we import contacts from Gmail, we add it >> to the database (phonebook_file_entry table) without >> checking for duplicate entries. This means that if you >> import your contacts from an account multiple times, it will >> create multiple duplicate entries of the same set of >> contacts in your database. > > I think this is valid for all types of import - csv imports as well. However, > the contacts are displayed only one time in the phonebook (they'll have the > same id in returned phonebook entries map).
Yikes! Good point about CSV imports. If we are calculating this entryKey when returning the phonebook entries map, we might as well use it when storing the data. >> Gmail assigns an unique resource id to each contact entry >> resource (ContactEntry.getId). At the minimum, we should >> store this id in the table, and use it to determine whether >> to add a particular entry to the table or update an existing >> entry. Ideally, we should store the versionId >> (ContactEntry.getVersionId) as well, and update existing >> entries only when the versionId has changed. > > Looks good - though it will introduce some overhead by performing the > validation for each potential contact. Another option would be to mark all > the contacts imported from a specific gmail account (so we'll know from where > they were imported). On a 2nd import attempt we can delete all the contacts > linked with the account and safely proceed with the new import. > Yep, that's a good idea, it would definitely be faster than individual validations. But, IMO we should also store the IDs. It might come into use in the future (e.g. if we ever look at updating the Gmail contacts through sipXconfig). I propose we add two columns to the phonebook_file_entry table, "id", and "gmail_id". For contacts imported through gmail, we set the "gmail_id" as the gmail address, and set the "id" as the resource id provided by gmail. For non-gmail contacts, lets use a hash of the entry-key as the "id" and set "gmail_id" to null. Or alternatively, instead of adding a "gmail_id" column, we could introduce a secondary table that maps "gmail_id"s to "phonebook_file_entry_id"s. What do you think? I will raise a JIRA to track this. Arjun _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
