Hi Patrick, There's a <datastore> level option called <updateallfields>, which is off by default, but must be switched on for database backends that always write all fields of a record, not only the assigned ones.
Originally, libsynthesis was used mostly with SQL databases, and the odbc backend normally generated SQL UPDATE statements which only included the fields that were actually supported by the peer, leaving other fields alone - which means that the database itself did the field-by-field merge operation. The same is possible with plugin DB adapters by distingusihing assigned from unassigned fields (and only updating the former), however with a vXXX format backend that obviously is not possible. Switching on <updateallfields> will cause the engine to do a read-modify-write cycle for updates to prevent loosing data. Lukas On 15.06.2011, at 15:41, Patrick Ohly wrote: > On Mi, 2011-06-15 at 13:02 +0100, Patrick Ohly wrote: >> One of the problems that we have in SyncEvolution is the loss of >> properties not supported by SyncML servers, like Google: >> https://bugs.meego.com/show_bug.cgi?id=15029 >> >> For example, BDAY is not supported and gets lost in a round-trip sync >> because the client doesn't know that the server didn't store the field. >> That's because the Google server does not provide CtCap as part of its >> DevInf. > > When I tested with CtCaps which mark BDAY as not supported, I still > don't get the expected result (BDAY preserved when importing update). > > The log confirms that the CtCap is used: > > [2011-06-15 15:32:19.605] using CTCaps provided in DevInf of remote rule > * [...] > * [2011-06-15 15:32:19.606] Field options > after CTCap analyzing: > * [...] > - BDAY : n/a > maxoccur=0, maxsize=0 (unlimited) > > What I expect to happen then is that the merge mechanism is triggered to > copy the available fields into the local database, as part of processing > the REPLACE operation. > > But instead the vCard provided by Google is sent directly to the local > database. Is there some way of turning on merging in this case? > > > -- > 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. > > > > _______________________________________________ > os-libsynthesis mailing list > [email protected] > http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
