After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 653548 - Contact's uid not immediately available after adding contact to addressbook
Contact's uid not immediately available after adding contact to addressbook
Status: RESOLVED NOTABUG
Product: evolution-data-server
Classification: Platform
Component: Contacts
unspecified
Other Linux
: Normal normal
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
Depends on:
Blocks: 638281
 
 
Reported: 2011-06-28 08:10 UTC by Raul Gutierrez Segales
Modified: 2011-06-29 15:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Create an e-d-s contact and query its UID immediatly afterwards (2.14 KB, text/x-vala)
2011-06-28 08:10 UTC, Raul Gutierrez Segales
Details

Description Raul Gutierrez Segales 2011-06-28 08:10:39 UTC
Created attachment 190830 [details]
Create an e-d-s contact and query its UID immediatly afterwards 

Why would this happen:

a) instantiate contact
b) set full name
c) add contact
d) get the contact's UID (field "id")
e) UID == NULL

Why wouldn't the E_CONTACT_UID field be immediately available?

Attaching a test case (in Vala).
Comment 1 Raul Gutierrez Segales 2011-06-28 12:40:47 UTC
As explained by Milan on irc:

mcrha | the EBook did modify EContact for you, but it's not done anymore, you are responsible for its modification, thus if add_contact returns uid, then you should e_contact_set it yourself

mcrha | rgs, the main thing is that the EContact is just a local storage for something you passed towards the server, and


This means that :

a) users should set the UID themselves on each EContact after its added (as noted by Milan)
b) you *should* listen to the objects_modified signal from EBookClient and update your original copy of EContact with the fresh one (otherwise you'll be holding outdated data)
Comment 2 Travis Reitter 2011-06-28 15:49:35 UTC
(In reply to comment #1)
> As explained by Milan on irc:
> 
> mcrha | the EBook did modify EContact for you, but it's not done anymore, you
> are responsible for its modification, thus if add_contact returns uid, then you
> should e_contact_set it yourself
> 
> mcrha | rgs, the main thing is that the EContact is just a local storage for
> something you passed towards the server, and
> 
> 
> This means that :
> 
> a) users should set the UID themselves on each EContact after its added (as
> noted by Milan)

Where does the client get this new UID? Or do they just pick their own? (if so, that seems like a fairly serious bug - only the server can know whether a new UID is valid.

> b) you *should* listen to the objects_modified signal from EBookClient and
> update your original copy of EContact with the fresh one (otherwise you'll be
> holding outdated data)

EContacts and EVCards aren't automatically updated? This seems like a fairly major change in behavior (from what I remember).
Comment 3 Raul Gutierrez Segales 2011-06-29 08:59:03 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > As explained by Milan on irc:
> > 
> > mcrha | the EBook did modify EContact for you, but it's not done anymore, you
> > are responsible for its modification, thus if add_contact returns uid, then you
> > should e_contact_set it yourself
> > 
> > mcrha | rgs, the main thing is that the EContact is just a local storage for
> > something you passed towards the server, and
> > 
> > 
> > This means that :
> > 
> > a) users should set the UID themselves on each EContact after its added (as
> > noted by Milan)
> 
> Where does the client get this new UID? Or do they just pick their own? (if so,
> that seems like a fairly serious bug - only the server can know whether a new
> UID is valid.

e_book_client_add_contact_finish has an out param to return the UID of the created contact. So you get it from there and you have to set it on the EContact if you wanna keep using it. 

> 
> > b) you *should* listen to the objects_modified signal from EBookClient and
> > update your original copy of EContact with the fresh one (otherwise you'll be
> > holding outdated data)
> 
> EContacts and EVCards aren't automatically updated? This seems like a fairly
> major change in behavior (from what I remember).

Yes. Milan mentioned this is the behaviour starting 3.1.2.
Comment 4 Travis Reitter 2011-06-29 15:37:27 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > As explained by Milan on irc:
> > > 
> > > mcrha | the EBook did modify EContact for you, but it's not done anymore, you
> > > are responsible for its modification, thus if add_contact returns uid, then you
> > > should e_contact_set it yourself
> > > 
> > > mcrha | rgs, the main thing is that the EContact is just a local storage for
> > > something you passed towards the server, and
> > > 
> > > 
> > > This means that :
> > > 
> > > a) users should set the UID themselves on each EContact after its added (as
> > > noted by Milan)
> > 
> > Where does the client get this new UID? Or do they just pick their own? (if so,
> > that seems like a fairly serious bug - only the server can know whether a new
> > UID is valid.
> 
> e_book_client_add_contact_finish has an out param to return the UID of the
> created contact. So you get it from there and you have to set it on the
> EContact if you wanna keep using it. 

OK, we'll just do that then. It seems odd that it isn't set by default though. There must be some rationale I'm missing.