On Mon, 17 Apr 2006 14:40:12 -0400, Peter Amstutz wrote:
>> http://dbstep.sourceforge.net/
> If it's not being maintained, perhaps we could fork our own version and
> import it into the VOS codebase. That would save some work.
Yeah, I suppose that's the best course of action.
> The current VOS SQL persistance uses bog-standard SELECT, INSERT and
> UPDATE statements. Anything SQL, son-of-SQL, grandfather-of-SQL,
> brushed-shoulders-with-SQL-on-the-subway, etc should support it.
DBStep is just plain old SQL. What changes is the access API -- it
provides a single, very simple and reasonable API, that works for all
database back-ends.
> b) There is no discrimination between properties, so data like position
> properties which might be updated ten times a second will be pushed to the
> database every time it is changed. It may be desirable to have some way
> of throttling that to avoid too much database traffic.
Good point.
> c) I'm interested in ways of recording change history so that previous
> states can be recovered. There is an experimental revision control
> plugin which has in fact been running as the backend for the hypervos
> section of interreality.org for a couple of years, but it is slow (it
> uses RCS as a backend for property data, and a history log file for
> vobject structure data) and the required tools to fetch manipulate the
> repository were never really developed. Something to think about would
> be a versioned SQL backend, which added a "version" column and only did
> inserts, keeping around old rows...
Yeah, I'm very interested on this... the requirement has come up
frequently on the design of my current project. You also mentioned in the
past storing wiki-like content, and history is essential for that.
A few versions down the road, I'd like the revision control subsystem to
be very complete, with most of the features you'd expect from bzr or svn
(from svn the ability for one vobject to "descend" from another, so you
can merge between them). Tracking vobjects -- as opposed to properties
only -- adds a few extra requirements.
- We'll be storing some marshaled representation of the child list;
probably leave the representation up to the persistence system? Or is a
standard representation necessary for merging across sites?
- Objects now have an "unique" id at this point in time -- the name they
have at the site root. For this system they need to *also* have an
unique-over-all-time id, which we can probably generate by prepending a
(creation) timestamp to the site id.
- So the way I see it, one revision of a vobject's child list is a list of
triplets: contextual name, persistent unique id, revision id.
- A revision of one object is... what? Off the top of my head, the
typeset, ACLs, child list, and if it's a property, prop type and data. Do
we track all of these separately (could cause less headache for merges),
or marshal everything to one large string? Or perhaps one string per
metaobject (so two in this case)?
Then there is the question of whether to store snapshots or some form of
delta-ish representation. In the last year we have been through exactly
this question with bzr and opted for weaves (or knits), so I suppose the
same reasoning probably applies; but not necessarily, since I believe the
data we'll be keeping will be typically more fine-grained (many small
objects rather than a few large ones).
Just throwing ideas around for reflection... it's probably too early to
marry any decision, since I don't see us spending too much time on this at
least for the next 2 releases :-)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we summon the will, they
soon become inevitable.
--
personal: http://www.laranja.org/ technical:
http://lalo.revisioncontrol.net/ GNU: never give up
freedom http://www.gnu.org/
_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
