> From: Branko Cibej [mailto:firstname.lastname@example.org]
> Bill Tutt wrote:
> >>From: Branko Cibej [mailto:email@example.com]
> >>Yes. Changing a unique ID is always a bad idea. Ben, d'you think you
> >>make that one property read-only? I'm afraid it probably means
> >>rudimentary access-control mechanism for revision props.
> >While Brane makes a great comment about ACLs and revision properties,
> >I'd like to point out at the filesystem level that the best place to
> >stick this information is in a new BDB table. Even if you expose the
> >table through the ra layers as a revision property, we're still
> >ahead of the game if we add a new BDB table for this.
> >The new table is very simple. All it needs at the moment are two
> >RespositoryID and GUID. RepositoryID is just another one of our fun
> >monotonically increasing ID fields, and the GUID column is the
> >repository GUID. The reason for structuring the data this way is that
> >eventually we'll want to widen at least the NodeRevision primary key
> >RepositoryID. We don't want to widen the NodeRevision PK by the
> >repository GUID mainly because GUIDs cluster so poorly on indices. No
> >need to waste valuable page &/or index space.
> I find myself agreeing with Bill yet again. :-)
> But perhaps we can work out a compromise: _this_ repository's GUID is
> special case, and we can always map it (later) to RepositoyID 0. Which
> means that we don't actually need a new BDB table at this very moment
> since we won't be widening the NodeRevision PK now -- but we _do_ need
> way to store the GUID and read it.
Although if mbk decides to grace us with a new BDB table and new ra
vtable methods to achieve our goal of a GUID, far be it from us to
dissuade him down this wonderful route. :) A new table certainly saves
us even more mess in the property handling code.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Dec 12 03:07:27 2002
This is an archived mail posted to the Subversion Dev