On Sat, 2016-12-10 at 15:52 +0000, Sam Thursfield wrote:
- Double checking ontology migration code, ensure it can handle weird ontology changes more or less elegantly.sounds good, but is this actually possible? I thought we found that it was too hard to really do this well, and it'll be quite a bit of effort
What can never be supported is for example converting a multi value property or predicate into a single value, without loss of data. And changing a xsd:string into xsd:integer like conversions without guaranteed zero loss of data, of course. But other than that, quite a lot is possible. The difficulty is detecting the the differences and knowing what to do. Doing it (the conversion itself), is rather simple. Just create new tables, copy old to new converting data in the process, delete old, rename new. The current code also has some pre and post handling here and there. All the different steps that are involved are what make it 'fun' to understand how it works ;-). You'll soon hate me when you have to start working on it. heh. (I hated myself often for not refactoring this into shape earlier on - it's code that, you know, grew Darwin style. It's a bit like a muddy pool with lot's of penguin, troll and frog poop). So please. Whoever starts working on that: don't be ashamed to throw away and redo it completely. I'll support you completely. Luckily this code rarely needs to run ... But when tracker-store is more a library, then I expect more users to flock to it and actually using it to store their metadatas in. And then this becomes increasingly important to support. Right now, upon a new release, device makers just throw the meta.db file away. And let the miners run again to fill it up again. The tracker-control binary even has command line support for just that. And I need to do it to my Jolla sometimes. Because that battery often comes loose. And then no fsync. And then meta.db becomes funny. What have we done ...
- Library-fying tracker-store, and separating ontology for good ....Yes!- And of course, keep dbus-based implementations around, I guess we can't move too far from nepomuk there, as it's already the implicit contract between miners and all the surrounding ecosystem. However would be great to have the tracker-store executable be more generic, so you can make it claim a different dbus name, write to a different location, construct the database using a different ontology...Yes.PS. I haven't forgotten the "big rip" thread, nor the "Resource table fills up with UUIDs" from further in the past, need to get back to those...One other thing to throw out here since we're on the subject of a roadmap, I don't have strong opinion on if/when this is adopted but I've been working on new build instructions using Meson: <https://git.gnome.org/browse/tracker/log/?h=wip/sam/meson>. They're maybe 75% complete at this point. Sam _______________________________________________ tracker-list mailing list tracker-list gnome org https://mail.gnome.org/mailman/listinfo/tracker-list
Attachment:
signature.asc
Description: This is a digitally signed message part