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

[Kevin Krammer]

> On May 30, 2013, 2: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?

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?


- Kevin


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


On May 30, 2013, 1:40 p.m., Christian Mollekopf wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/110648/
> -----------------------------------------------------------
> 
> (Updated May 30, 2013, 1:40 p.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/entity.h a7fb808be2434450f836bd74109627c431da6934 
>   akonadi/entity.cpp fb76859ccde47971651d56ea2ea6cfd6aad84e41 
>   akonadi/entity_p.h 9ed012c5a4433a94b36846bf7f95d93931aae4c7 
>   akonadi/gid/gidextractor.h PRE-CREATION 
>   akonadi/gid/gidextractor.cpp PRE-CREATION 
>   akonadi/gid/gidextractorinterface.h PRE-CREATION 
>   akonadi/gid/gidmigrationjob.cpp PRE-CREATION 
>   akonadi/gid/gidmigrationjob_p.h PRE-CREATION 
>   akonadi/itemcreatejob.cpp 9d3924848ec3f70c1d328576451319241e64b678 
>   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/