Apr 12 2023
Jan 17 2022
Meanwhile the Thunderbird Addon is no longer maintained and usable.
Nov 19 2021
Aug 5 2021
Jul 4 2021
Apr 25 2021
Apr 14 2021
Ok, I'll create new merge request soon. Thanks.
Apr 13 2021
It would help, if you would summit a merge request on invent.kde.org: https://invent.kde.org/pim/akonadi/-/merge_requests
From first glance the patch seems fine. But we will look in more detail, if you summited a merge request, as it has a much better interface to give feedback.
Apr 12 2021
Hello Daniel,
Mar 6 2021
Thank you Carl for looking into this! This task is probably the biggest porting blocker for PIM, I'm very happy to see we have a way forward for this now :)
Mar 2 2021
PoC MR: https://invent.kde.org/pim/kmail-account-wizard/-/merge_requests/2 There is still a lot to do but it seems the approach is viable.
I started the port in work/qml branch (https://invent.kde.org/pim/kmail-account-wizard/-/tree/work/qml). It is using KPackage for loading the wizards, so it will require updating all the existing wizards but since I was able to expose the existing SetupManager without much changes to the QML engine, it probably won't be that hard to port everything to QML.
Feb 10 2021
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.
Feb 9 2021
well if limit of the PimItem.id comes into the game we need a subqueries, anyways.
Feb 8 2021
Makes sense that views don't optimize. I was hoping we could avoid scanning the large PimItemTable multiple times and just reuse the list of pim items in the flags/parts/etc. queries. I guess there's no fast way to do that without stored procedures (and creating a temporary table would be too expensive).
Feb 7 2021
I think I can handle it. Thanks for help.
@kondzio : yes that is what Daniel recommended, but a temporary view cannot be optimized.
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.
But why create temporary views? No human is creating the queries. Views do not improve the speed in anycase. If you only construct a view for one request it only makes the resulting query nicer to read. But no speed improvement. I think the first idea of @dvratil for the query is fine:
Feb 6 2021
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?
Oct 29 2020
that's a good point. I would say that adding a getter to QueryBuilder to get the mTable field and using that in QueryHelpers is a good design decision.
Oct 28 2020
background support is now on the way to enter: https://invent.kde.org/pim/messagelib/-/merge_requests/15
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.
Sep 24 2020
Sep 23 2020
Hi Konrad! This may be a pre-requisite for T645, but it is not directly related to it.
Sep 22 2020
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.
Sep 21 2020
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.
Great work, Konrad! Many thanks for improving KAddressBook!
Sep 19 2020
Thanks, that was my first assignment and I'm pleased to be able to contribute.
really nice work :D
Hi Daniel,
It seems to me that changes for this task are finished.
Sep 8 2020
Aug 14 2020
@knauss Did any development occur? On NLNet I see the project is still at 'Open' status.
Jun 22 2020
May 25 2020
Marked as Solved as per https://phabricator.kde.org/D29604 and https://invent.kde.org/pim/akonadiconsole/-/merge_requests/1 were accepted
May 21 2020
This fixes the Agent sorting.
May 8 2020
May 1 2020
Me get funding from nlnet to work on this. The rough ETA is to finish this in June.
Apr 30 2020
Apr 29 2020
Daniel, I think I have finished preparing my changes. How will we process this further? Should I send my changes someone to review?
Apr 22 2020
any updates?