Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stellation-res] Database abstraction

On Tuesday 13 August 2002 07:00 pm, Florin Iucha wrote:
> On Tue, Aug 13, 2002 at 02:06:39PM +0000, Mark C. Chu-Carroll wrote:
> > So... I'm looking at trying to create a database abstraction layer that
> > will work accross Postgres, DB2, Oracle, MySQL/InnoDB, and
> > Firebird.
> >
> > One option is to totally automate the SQL generation process. This
> > allows us to smoothly handle things like the INNODB declarations
> > that need to go onto the end of table creations, variations in typenames,
> > etc.
>
> Mark,
>
> Please let down the Java hammer for a while. This can be trivially done
> with a bit of templating in Perl. Nice and clean.

I don't think this will work that way. It's actually an approach that
I considered... But with the decoupled nature of Stellation, I don't
see how to make it work. It could just be that I'm brain-dead today.

I also think that there's something rather ugly about that SQL
generation code. It can be somewhat cleaned up - but the basic
problems of the approach will remain.

The catch which causes the problem is that the SQL isn't all in one place. 
There's the DBAccessPoint, which has the SQL code for creating
the intrinsic tables. Then each of the agents has its own SQL for
creating and manipulating the tables for its artifact type.

So the templating approach is difficult... How do we make sure that
an ArtifactAgent author can provide a binary Agent implementation that 
can adapt itself to whatever database the user selects? The only way
that I see is to make it a dynamic behavior dependent on a component
with knowledge of the database.

	-Mark
-- 
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




Back to the top