[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Marketing blocker collection, DEADLINE: 2013-03-10
From:       Volker Krause <vkrause () kde ! org>
Date:       2013-03-03 17:37:09
Message-ID: 5505307.jkGNivQ8Cu () vkpc9
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 03 March 2013 19:11:22 Andras Mantia wrote:
> Volker Krause wrote:
> > Also don't forget that the path string changes for entire sub trees if you
> > rename a folder. And we also need identifiers for addressing data in
> > Nepomuk, for every item.
> 
> Just a note, this is what we run into with my latest patch: if a folder is
> renamed or moved, the filters won't work. Previously this was supported.
> Suggestions welcome. :)

that's why we used move-invariant ids in the first place...

See below for a possible approach.

> > Much more interesting than these workarounds is IMHO: why do you want to
> > delete the database? Providing proper solutions for these use-cases seems
> > much more useful to me.
> 
> Well, reasons:
> 1) failed migration

delete the account that failed, that'll remove the associated data without 
invalidating id mappings

> 2) changing database backend (e.g on distros defaulting to sqlite)
> 3) switching from local db to shared database

technically the solution for this would be more something like an SQL 
dump/replay, right?

> 4) database corruption/file system corruption

Both the database and file system have recovery tools that are automatically 
run (by the OS or us, respectively), but let's assume both failed on the 
database and the database only.

In this case you have to manually intervene and bring the system back into a 
defined state, which means replaying a previous backup, or removal of the 
entire state if you don't have one. This isn't really any different from a 
corruption somewhere else. If you have a damaged .so, just deleting this one 
wont fix the system either.

> And there is of course also the syncing issue.

Sure, this is a valid use case but is not a reason to delete the database ;) A 
working id mapping can actually help with this: use the path only for 
export/import (so you don't have to maintain it on renames), and otherwise 
stick with move-invariant ids. Combines the best of both worlds, but requires 
dedicated import/export tools, it wont work with just a basic rsync.

regards,
Volker

["signature.asc" (application/pgp-signature)]

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

[prev in list] [next in list] [prev in thread] [next in thread]