Hey,
>
> Glen Thompson mentions the issue of providing a pluggable DB layer
> before addressing DASL-like functionality. I'm curious as to the
> reason Glen feels this way - is there a compelling architectural
> reason for this? We took the opposite approach wrt Catacomb,
> implementing DASL support first, and now are beginning to address
> pluggable DB backends. The Catacomb DB schema is simpler than that of
> Subversion, yet a layer of indirection could be provided in supporting
> DASL such that a search handler is provided along with the DB access
> layer needed to support a given DB? Bolting on search after designing
> pluggable-db would seem to require some reengineering effort because
> the way DASL is implemented will depend largely on the storage layer
> implementation.
Well this is not easy for me to answer. When you say "Glen Thompson
mentions the issue of providing a pluggable DB layer before addressing
DASL-like functionality", it makes it sound like I made a conscious
decision to address one before the other. This is simply not true.
Subversion has well defined goals. It's not for me to decide the overall
design priority for Subversion. Subversion also has a *well* defined FS
API (um, I'd like to change a few small things;-)). I'm merely trying to
tweak it to allow several technologies to live under that API.
Subversion is not just about WebDAV. It currently has three separate
access mechanisms. Also, as you pointed out, the Catacomb schema is
simpler than Subversion's. I think it's a big enough task to implement
what is there without adding new design constraints:-) Please read
"subversion/libsvn_fs/structure" and "subversion/include/svn_fs.h" if
you haven't already done so.
As to why I'm working on this:
IMHO, BDB just will not handle what I want to do. I just checked; we
have over 100GB of data in two Samba file systems (un-versioned). The
strings table is bound to get pretty ugly don't ya think. DBMSs like
Oracle, MySQL(InnoDB), and SQLServer have "tablespaces" and LOB support.
These features will come in handy for someone in my situation. Some
might argue that there are better ways to handle this. I will not be
drawn into one of those discussions. I want a SQL solution; someone else
will want a file system based solution. Others will want a combination
of the two, and so on.
I'm trying to create an environment where we can all play together
nicely. In fact, I believe that pluggable-fs is a better term than
pluggable-db . As the old saying goes; keep your eye on the ball. I
believe the "ball" is the existing FS API. Its pretty good. Im working
from there. I'm also trying to make sure that the existing FS
implementation can be re-used with other data stores for those not
wanting to spend massive amounts of time re-inventing the FS wheel. e.g
a "pluggable-db".
I'm trying to get a document out, but you know how it is! Stuff Happens.
Stay tuned.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 30 23:06:09 2003