Hello! When storing contacts in Evolution Data Server, SyncEvolution applies a <beforewritescript> which massages the contact such that it meets Evolution conventions. For example, the VOICE flag must be set for TEL, because otherwise Evolution ignores the number.
This leads to the following situation: * Contact with TEL;TYPE=WORK:1234 is received. * It gets processed and before writing, the flag is set => TEL;TYPE=WORK,VOICE:1234 * The next sync is a slow sync, so the incoming item (absolutely unmodified!) gets compared against the one from the datastore. * Because the datastores' and the incoming items TEL flags are different, the engine concludes that the DB item must be merged and updated in the DB. * Because the same <beforewritescript> is again applied after the merge, the exact same item gets sent as update to the DB, without changing anything. This leads to one unnecessary database operation, which is undesirable when slow syncs are frequent and the storage resides on flash storage. This is the case for syncing with PBAP in IVI. IMHO the "adapt item to what is expected by data store" step should be applied to the incoming item *before* processing it, in other words, in the <incomingscript>. If processing then doesn't break the item again, the script does not need to run again before writing. But the SySync_config_reference.pdf explicitly warns against that: "Note that this is not the place to implement database specific conversions, because this is better done in the <beforewritescript> and <afterread-script> in the <datastore> section". Is that because normally, datatypes are shared between different data stores? I could avoid that by defining datatypes such that they only get used in exactly one data store. The putting data store specific transformations into the datatype's <incomingscript> would be okay, wouldn't it? -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis