Le 28 oct. 2010 à 06:51, Niels Grewe a écrit : > On Wed, Oct 27, 2010 at 04:00:48PM +0100, David Chisnall wrote: >> On 27 Oct 2010, at 14:17, Quentin Mathé wrote: >>> On this topic, I had a long discussion with Nicolas one year ago about >>> using the metadata db just as a cache to make CoreObject as resilient as >>> possible. By scanning a volume and storing the right informations in each >>> object store, we could support to reconstruct the core object graph and the >>> metadata db from scratch. >>> >>> David was advocating another approach, storing less things in each object >>> store and relying more on the metadata db. For instance, to store simple >>> property changes in the metadata db and not in the object store, the object >>> store would be reserved for non-trivial delta changes (e.g. range editing) >>> and snapshots. I'm not convinced by this approach because it creates two >>> persistence code paths, and means that you cannot simply move an object >>> store around without extracting the trivial changes stored in the metadata >>> db. This also implies that recovering from a metadata db corruption is not >>> possible. If we go this way, it might be better to put everything in the >>> metadata db. >>> However I must admit, that we'll need to tag methods triggering persistency >>> in some way to immediately index the changed property values in the >>> metadata db (supposing we want to support temporal versioning). And this >>> problem is kinda orthogonal to David's suggestion. If we don't do that we >>> need to have a standalone process that deserializes recently touched core >>> objects and indexes them, this is much more complex and costly. >>> >>> I quite like Nicolas' approach, although it's going to cost some space >>> (replicating property changes in the metadata db and the object store). >> >> I think I mostly agree with Nicolas here too. Having two code paths for >> persistence is complicated. My point with regard to metadata was that you >> should be able to modify an object's tags without having to load the object. >> > > I missed that point yesterday, but for the record: I also think storing > the metadata in the store is the way to go. It probably facilitates > passing objects around for whiteboarding etc. Retrieving it without > deserializing the whole object graph shouldn't be too difficult if we > keep it separated.
Currently you can tag/organized the core objects without loading them. Just put the object in a group. So I'd say we already support David's requirement. However metadatas can mean many things, so we need to be precise about what we are referring to: - ES/CO internal metadatas (archive format, version, metadata db identity etc. attached to an object store) - Groups to which core objects belongs to (this serves an organizational and basic information sharing purpose similar to a name service) - Intrisic metadatas about a content (ID3, Exif, IPTC, Dublin Core etc. including our own set of formalized metadata sets) stored as core object properties and indexed… However you have to load the core object to edit them or add new metadatas. Unless the content is initially created inside Étoilé, these metadatas also have to be imported (e.g. Mélodie or MediaKit uses TagLib). - Other core object properties (contact, calendar event etc.) indexed in the metadata db. Some additional comments… Indexing means replicating the property value into the metadata db to support querying it. For each core object, the metadatas indexed in the metadata db is a subset of its properties (here I don't count groups or tags as metadatas). CoreObject will support loading/editing core object properties with a fallback class or a tailored class per use case (that's the NewtonSoup main idea and what the AddressBook framework supports too); to give a concrete example, a ETMusicTrack core object can be loaded as a generic COObject (properties/metadatas specific to ETMusicTrack and not defined at COObject level will be masked). I think we should come up with a precise terminology for each metadata kind and put it on the website to have a common ground for future discussions. Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
