On Mi, 2011-05-11 at 09:45 +0200, Patrick Ohly wrote: > On Mo, 2011-05-09 at 12:57 +0100, Patrick Ohly wrote: > > It's probably just my ignorance of the Qt testing framework. I was > > looking for a way to run individual tests, because right now the first > > one hangs for me: [...] > After looking at this some more I believe that there is a race condition > in the test and/or the QtMobility API: a contact is added and removed > quickly. A "contact added" signal is emitted, followed by a "contact > deleted". Hypothesis: these signals are processed by their recipient > after the contact was already removed. The D-Bus log below supports that > hypothesis. I haven't verified it by looking at the test source code and > adding printfs.
I really should have... I would have found much earlier that I was running with an old libqtcontacts_eds.so. But after looking at this failure around "last modified" time stamp I might have to point out a conceptual problem: currently, the QContactTimestamp "lastModified" detail (= REV property) is set by QtContacts-EDS before creating or updating a contact. Is there a guarantee that this value is really stored as-is in EDS? It's undefined at best; looking at the source code, I see that e_book_backend_file_modify_contact() overwrites REV whereas e_book_backend_file_create_contact() only updates it when it is empty. So we return a potentially wrong "last modified" value for updated contacts. We have to retrieve the contact from EDS after saving to be 100% sure about the right value. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
