Re: [stellation-res] A database proposal, for fixing 22135.

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

On Friday 09 August 2002 02:45 am, Florin Iucha wrote:
> On Sun, Aug 04, 2002 at 08:10:13PM -0400, Mark C. Chu-Carroll wrote:
> [snip]
>
> > OK. Enough background. Here's what I'd like to do.
> >
> > I'd like to separate the tags from the lines in the database. And I'd
> > also like to burst the tags out, so that instead of bunding the
> > information about what versions a given line is part of into a tag
> > string, it gets broken out into a bunch of lines in a different table.
> >
> > So... The Texts table becomes two tables: TextLines, and TextVersions.
> > Each row in TextLines is an artifactID, and a line ID, and the line
> > string.
> >
> > TextVersions is a list of (linenumber, LineID, VersionIDs). There is an
> > entry in TextVersions for a LineID,VersionID if the line is a member
> > of the version.
>
> There is something that bugs me for a couple of days...
>
> Stellation is plugin based: each artifact is [supposed to be] manipulated
> by a plugin that knows how to parse/merge/diff it.
>
> If that't the case, why is the database schema assuming that text files
> can be _meaningfully_ sliced into lines of text?

That's the database schema for *text* artifacts. 

The idea is that as you add artifact types to the system, you provide
a database scheme for that artifact type. The ArtifactAgent (the
plugin type that provides a new artifact type implementation)
has methods to create the database tables needed to support
the artifact type, to retreive and store artifacts of the type from and
to the database, etc.

So what we're talking about is the implementation of TextArtifactAgent. 

If you didn't want to use table layout that we're discussing, you'd
implement a new agent that created tables to store things however
you choose.

For instance, we've been discussing supporting XML schema's
with another IBM group. They don't want the kind of storage that
we do for simple text; they want sliced-and-diced storage of meaningful
chunks of the schema. So they'd use something more like the list of
LOBs that you suggest. 

> Shouldn't the stellation core store the artifact data in whatever format
> it pleases (simple linked list of blobs containing data/delta or files
> stored at filesystem lever or ...) and serve it to the appropriate plugin
> as a big chunk'o'bits?

But then we're dictating to the artifact type implementors that they
have to use that BLOB implementation, even if there's a reasonable,
efficient, easy to read and manipulate representation of their type
in a set of tables. Our approach is to not dictate storage 
at all, except that it needs to be in the database.

	-Mark



>
> florin

-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work Email: mcc@xxxxxxxxxxxxxx  ------- Personal Email: markcc@xxxxxxxxxxx