Re: (SoC) SQL storage option for libsvn_fs_base

Edmund,

When you start looking into the schema design in more detail, the
following article discussing how to store Trees in SQL might be
helpful.

----
Trees in SQL: Nested Sets and Materialized Path
by Vadim Tropashko
Relational databases are universally conceived of as an advance over
their predecessors network and hierarchical models. Superior in every
querying respect, they turned out to be surprisingly incomplete when
modeling transitive dependencies. Almost every couple of months a
question about how to model a tree in the database pops up at the
comp.database.theory newsgroup. In this article I'll investigate two
out of four well known approaches to accomplishing this and show a
connection between them. We'll discover a new method that could be
considered as a "mix-in" between materialized path and nested sets.
----
http://www.dbazine.com/oracle/or-articles/tropashko4
Kind Regards,
John Fallows.
On 6/9/05, Edmund Horner <ejrh@paradise.net.nz> wrote:
> Hello everyone.
> 
> You might recall my on-again-off-again interest in storing Subversion
> data in SQL; well, I've begun to think about it again and come up with a
> new plan for doing it.
> 
> I'm going to submit this application to Google's Summer of Code, but I
> thought I'd air it here first in case there are obvious things I'm
> forgetting about.
> 
> Please comment by 14 June. :-)
> 
> 
> 
> 
> Google "Summer of Code" proposal for the Subversion project
> 
> Edmund Horner
> ejrh@paradise.net.nz
> 
> 
> SQL STORAGE FOR THE LIBSVN_FS_BASE FILESYSTEM BACKEND
> 
> The storage layer of libsvn_fs_base will be abstracted, and an
> implementation of an SQL storage option will be added alongside the existing
> BDB storage option.
> 
> Benefits:
> 
> The benefits of this contribution will be a complete first SQL filesystem
> backend, and the increased querying options that this will bring to
> Subversion administrators.  For instance, queries such as "which file
> revisions have property foo?", or "which files are direct or indirect copies
> of /trunk/README?" will be efficient and available as SQL queries.  Another
> possible benefit of the SQL filesystem is repository replication.
> 
> Deliverables:
> 
>   * Storage layer abstraction in libsvn_fs_base, with the BDB storage option
>     continuing to work as before.
> 
>   * Addition of an SQL storage option, initially storing data in a PostgreSQL
>     database.
> 
>   * SQL functions for exploring the repository in an SQL client.
> 
> Details:
> 
> The BDB-specific functions (mostly in the bdb subdirectory) will be further
> separated from libsvn_fs_base.  A storage vtable will be created, which will
> be used anywhere that the code currently calls a BDB function directly.
> This vtable structure will be private to libsvn_fs_base.
> 
> An SQL implementation of the vtable will be created, with a very similar
> structure to the BDB implementation.  Schema changes will include using
> integers for unique identifiers, replacing skels with individual SQL
> attributes, and storing properties and directory entries as individual rows.
> 
> SQL functions for queries like those mentioned above will be written and
> automatically created as part of repository creation.  These functions will
> be designed for human exploration of the repository filesystem.
> 
> Changes will occur in libsvn_fs_base, with the exception of additional
> command-line arguments to svnadmin for repository creation (and the passing
> of those arguments through to libsvn_fs_base).
> 
> Schedule:
> 
> Work will began full-time after my last mid-year examination on 18 June.
> I have already spent some time recently improving my familiarity with the
> existing filesystem backends.  I can work full time on it until 4 July, when
> the second half of the study year begins.  After that I will continue work
> at a slower pace.
> 
> If there are no contradictions in the design, I believe the work can be
> completed within 2 or 3 months part-time.
> 
> Biography:
> 
> I am a student at Victoria University of Wellington, studying Mathematics
> and Computer Science.  I will likely complete a Bachelor of Science degree
> in the first half of 2006.
> 
> I have been a Subversion user since November 2002, and until now have taken
> a mostly-passive interest in its development.  I worked on a short-lived
> MySQL-based filesystem backend in early 2004, and also contributed one small
> patch (issue #1861 "library version checks", r10167) in July 2004.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> 
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org