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. Cheers, Niels _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
