ItemFetchJob / ItemCreateJob Answer ?

[Daniel Vrátil]

On 2017-04-28 22:42, Martin Koller wrote:
> On Donnerstag, 27. April 2017 22:56:10 CEST Daniel Vrátil wrote:
>> On Thursday, April 27, 2017 8:11:57 PM CEST Martin Koller wrote:
> 
>> > Isn't there a possibility to answer just with some "here is the mail"
>> > response without even getting into the problem in the akonadi server of
>> > having to check if there are "multiple merge candidates" ?
>> 
>> itemsRetreived() passes the Items to the ItemSync, which then does its 
>> magic
>> as desribed above. Theoretically, if the Item ID is known, ItemSync 
>> could use
>> ItemModifyJob instead of ItemCreateJob, and fallback to ItemCreateJob 
>> (in
>> merge) mode only if ID is not known.
>> 
>> Maybe even better, as a server-side optimization, the AKAPPEND handler 
>> could
>> perform merging based on ID if ItemID is present in the command and 
>> fallback
>> to GID/RID merging otherwise. This would be more efficient, because 
>> querying
>> Items from DB based on ID is faster than RID/GID queries (because of 
>> DB
>> index).
> 
> I'm looking into this. However, do I see this correctly that the
> CreateItemCommand
> does not transport an item id ?

It does not. Historically, CreateItemCommand (AKAPPEND) was only used to 
create
new Items, and of course there's no ID when you are requesting Item 
creation.

I thin for the start, we should try with just issuing ItemModifyJob 
instead of
ItemCreateJob from ItemSync if the Item has a valid ItemID. We can 
consider
changing the Protocol later...I'm still not sure if there might be any 
side-effects
to ID-based merging.


> If so, I assume this can be added, right ? (but how I don't know since 
> there is
> generated code ...)

Check src/private/protocol.xml - the syntax is rather obvious, I'd say 
:-)

Dan


-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)