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
