ItemFetchJob / ItemCreateJob Answer ?

[Martin Koller]

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 ?
If so, I assume this can be added, right ? (but how I don't know since there is
generated code ...)

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\                        - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at