Ok, I'll create new merge request soon. Thanks.

Hello Daniel,

In my opinion approach with subquery is better because I made a small comparison with a similar query on "Employees Sample Database" from dev mysql site.
I used similar queries to ours, because I don't know how to do execution plan with estimating cost on the lower version of MYSQL,
but from what I see limiting set is done before doing JOIN and the final query cost is much lower than in the second case.

I think I can handle it. Thanks for help.

I thought Daniel recommended creating a temporary view, because he wrote in his last statement:
"However, we could optimize this and create a temporary view with the filtered, limited results on the PimItemTable first, then use the view in the additional queries, then destroy the view again ".
It seemed to me it has sense because there is currently no functionality that the QueryBuilder class can use to nest a subquery in the main query FROM clause, unless I missed something.

Hello Daniel,
I encountered another problem while working on this task.
How are we should creating a temporary view? from what I know MYSQL doesn't support temporary views.
Initially, I tried to create a view based on a query that returns the buildItemQuery function only if ItemFetchJob had a limit greater than zero,
and when it was no longer needed I removed it at the end of the ItemFetchHelper::fetchItems function.
Next I added the functionality which prepending id to the view name, because each connection/thread on the server may have a different limit at the same time, and I also added a mutex locking functionality when each new view is creating.
In this approach I see one potential risk in situation when exception occurs (e.g. closing connection by client) between creating and deleting view, then created view will never be deleted.
Can You help me how to deal with it? or maybe there is an easier way to do it?

Hello Daniel,
Could You please advise me ?
The main problem for me with implementing these changes is that every function that builds its own query in ItemFetchHelper, for example buildPartQuery finally calls ItemQueryHelper::scopeToQuery(mScope, mContext, partQuery)
All these helper functions in ItemQueryHelper: scopeToQuery, gidToQuery, remoteIdToQuery, itemSetToQuery which generate additional where clauses have hardcoded table and column names for PimItem and are also used in many other places not only in ItemFetchHelper.

Now I understand how this should be implemented, more or less. Daniel if You only answer my first question I think I could start working on it.

Hello Daniel,
I would like to try to implement this task. Can this task be implemented separately, or is it somehow related to the task T645?
Do you have any information that would make it easier for me to start coding? because currently I have little knowledge about Akonadi.

Thanks, that was my first assignment and I'm pleased to be able to contribute.

Hi Daniel,
It seems to me that changes for this task are finished.

Daniel, I think I have finished preparing my changes. How will we process this further? Should I send my changes someone to review?

Hello Daniel. Could you tell me what photo or description should we display for a group contact ? Which phone number and email address should be displayed for single contact ? home or preferred ?
See the screenshot in the attachment, I prepared an example solution. Are you sure that we want to display two smaller pictures one below the other? or the appearance on the screen is acceptable in your opinion?

Daniel, I want to prepare a solution for this task, but I can't find a way to get an email address in added delegate inside paint event when the email address column is hidden. I tried to get it from the model but it only contains the columns that are visible in the GUI. Can you help me with this?