[Kde-pim] Review Request 110648: Gid support for kdepimlibs

Dan Vrátil dvratil at redhat.com
Sun Jul 28 09:22:51 BST 2013



> On May 30, 2013, 4:37 p.m., Volker Krause wrote:
> > I'd not run the migration in-process or blocking in any way. Let's put it into a separate background process.
> > I expect this to take time and cause considerable CPU load, to let's not hurt unrelated applications with this by not showing up anything before the migration is done. Bad experience with that approach ;-)
> 
> Christian Mollekopf wrote:
>     Hmmm... I wanted to have it blocking so we can afterwards immediately rely on gid lookups to work. But since it will indeed involve fetching all payloads.... Maybe a migration agent in kdepim-runtime? Would autostart and do the migration.
>     The agent could eventually be extended with other migrations, controls, etc.
> 
> Volker Krause wrote:
>     Yep, a migration agent is fine, a one-off migration process similar to the kres-migrator would also be ok I guess (see Akonadi::Firstrun). The agent is fully self-contained (no modifications in the Akonadi client lib required), and will automatically exist in exactly one instance, but it will also run when not needed (that's a problem is shares with a few others, we need to look into optimizing that eventually).
> 
> Christian Mollekopf wrote:
>     I don't think it matters that the agent runs always. It may even be a good place to check the status of a migration, and to trigger a rerun of a migration.
>     But can we get the other changes in first before I add the migration agent?
> 
> Kevin Krammer wrote:
>     Great, my review from yesterday didn't make it :(
>     Generally anything that involves data when migrating should not be done by blocking application startup. This was a very bad idea for mail. Worked for the kres migrator because it essentially only modified config.
>     
>     I don't see why the agent would need to be always running. It could be triggered like any other migration process and remove itself from the agent setup once its done.
>     
>     One thing I am wondering about is how this agent would work. Would it fetch all items (cache only of course) and do motify jobs on them? How do we make sure that at least the resources don't get change notifications?
> 
> Christian Mollekopf wrote:
>     I guess that's possible as well. Note that we might want this migration to run again if new GidExtractors become available (on a per mimetype basis).
>     The migrationjob supports this by getting a list of mimetypes to migrate, which it filters by the types already migrated (from a configfile).
>     
>     The migration then indeed fetches all items cacheonly, and executes an ItemModifyJob with ignored payload. The resources will get a notification (no idea if we can prevent that), but they could filter it by looking for the "GID" part.
>     
>     
>

You can set ChangeRecorder in AgentBase to always ignore all notifications from "akonadi_migration_agent" session (or whatever the migration agent's default session will be called).


- Dan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110648/#review33437
-----------------------------------------------------------


On July 28, 2013, 12:54 a.m., Christian Mollekopf wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/110648/
> -----------------------------------------------------------
> 
> (Updated July 28, 2013, 12:54 a.m.)
> 
> 
> Review request for KDEPIM and Volker Krause.
> 
> 
> Description
> -------
> 
> Added support for GID.
> 
> This patch adds support for a globally unique identifier, which is extracted from the payload using the GidExtractorInterface, allowing to fetch items based on the GID. The GID is typically a globally unique UID, such as the UID fields in ical and vcard.
> 
> For testing I added the possibility to inject a testplugin to override the plugin lookup.
> 
> The migrationcode is still missing: I'll add a GidMigrationJob which is run during the servermanager start, which would simply fetch all items of a given mimetype (where we have gid support), and set the gid for each item. From then on gid based lookups should work reliably, allowing for efficient fetching of items which are referred by gid (contactgroups, ical relatedTo).
> 
> 
> Diffs
> -----
> 
>   akonadi/CMakeLists.txt 04a206bed4a9fc08f798ce6116d2eed3f1b13360 
>   akonadi/gid/gidextractor.cpp PRE-CREATION 
>   akonadi/gid/gidextractor_p.h PRE-CREATION 
>   akonadi/gid/gidextractorinterface.h PRE-CREATION 
>   akonadi/item.h 1ece4e5f7f6e5e4ca076a1d16a058233e2367168 
>   akonadi/item.cpp e160ad53ad564ffbf62c3dcae2c349f21d944fc3 
>   akonadi/item_p.h a3417cf606bbab7516ab37279bca8d2b0d53685d 
>   akonadi/itemcreatejob.cpp 9d3924848ec3f70c1d328576451319241e64b678 
>   akonadi/itemfetchscope.h 3ce00fdec021eb9bd5e62da43a399208ce2997e9 
>   akonadi/itemfetchscope.cpp ab98921aec51a77b89257280b85f1e9d5b0a4357 
>   akonadi/itemfetchscope_p.h e7f5f15eed627f231c8a39d032a049eacb345347 
>   akonadi/itemmodifyjob.cpp d81b443dbac0aa96f9092cc7a3700c61aebc4db2 
>   akonadi/itemmodifyjob_p.h 43ec38c2f349859d78158dce8a3499eada25c073 
>   akonadi/itemserializer.cpp be5c263919915716567db713b9b9de60ab5a64dc 
>   akonadi/itemserializer_p.h 5d3f0a67f17c4b9f39b803a5bd335117697f6430 
>   akonadi/protocolhelper.cpp 8e5c088af13c5d9924cf4926349cf8ff4d1064f4 
>   akonadi/protocolhelper_p.h 4f8f3bb5edc493fb36b2609cc9a8fdcbd15e8e38 
>   akonadi/tests/CMakeLists.txt 6ac1538da358b33b752ae8511516bf0f684c04ea 
>   akonadi/tests/gidtest.h PRE-CREATION 
>   akonadi/tests/gidtest.cpp PRE-CREATION 
>   akonadi/typepluginloader.cpp 47683c8144696215e71d4b4628f6a8192622aec8 
>   akonadi/typepluginloader_p.h 659638ca7fdc802ded56f1a7b3e7f129913cc46c 
> 
> Diff: http://git.reviewboard.kde.org/r/110648/diff/
> 
> 
> Testing
> -------
> 
> manual testing, gidtest.
> 
> 
> Thanks,
> 
> Christian Mollekopf
> 
>

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/



More information about the kde-pim mailing list