Re: [stellation-res] Database abstraction

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

On Tuesday 13 August 2002 06:37 pm, Marco Qualizza wrote:
> Without being too critical, I don't think that you're being abstract
> enough.  ie/  It looks like you're trying to rebuild the String with
> method calls, instead of, for example, just creating a
> ForeignConstraint object and having a
> addConstraint(ForeignConstraint constraint)...

I did consider that... Before I went all out and went to that level of
abstraction, I wanted to be sure that this general approach of 
abstracting out to command objects that mask the underlying SQL
wasn't totally insane. (I'm working today in the pattern of 5 minutes
of hacking, five minutes of playing with my sick 2yo daughter, so
I'm never really getting a chance to think all the way through
anything.. So before I blew the rest of the days work on this approach,
I wanted a sanity check.)

	-Mark



>
> but that's my $.02 (approx. $.013 after exchange with the States...)
>
> Tuesday, August 13, 2002, 10:06:39 AM, you 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.
> >
> > I've tried a first cut at doing this for table creation. I'm looking at a
> > bit of test code, and I can't decide whether I like it (it's nicely
> > abstract, and quite easy to write), or hate it (it's hard to see the SQL
> > in it). Here's a sample: what do you folks think: is this a good
> > direction, or am I being idiotically abstract?
> >
> > Here's the original SQL:
> >
> >         CREATE TABLE Properties (INTEGER aid,
> >                                                 INTEGER vid,
> >                                                 INTEGER inheritable,
> >                                                 VARCHAR(200) name,
> >                                                 VARCHAR(1600) value,
> >                         CONSTRAINT fk3 FOREIGN KEY (aid, vid) REFERENCES
> > Versions(aid, vid) PRIMARY KEY(aid, vid, name))
> >
> >
> > Here's the corresponding code:
> >         DatabaseCreateTableCommand cmd =
> >                     _db.createTable("Properties")
> >                         .addIntegerField("aid")
> >                         .addIntegerField("vid")
> >                         .addIntegerField("inheritable")
> >                         .addShortStringField("name")
> >                         .addLongStringField("value")
> >                        .beginForeignKeyConstraint("fk3", "FOREIGN KEY")
> >                             .addConstraintField("aid")
> >                             .addConstraintField("vid")
> >                            .beginForeignKeyReferences("Versions")
> >                              .addConstraintField("aid")
> >                              .addConstraintField("vid")
> >                            .endForeignKeyConstraint()
> >                        .beginPrimaryKeyConstraint()
> >                           .addConstraintField("aid")
> >                           .addConstraintField("vid")
> >                           .addConstraintField("name")
> >                        .endPrimaryKeyConstraint()
> >                      .endCommand();
>
> _______________________________________________
> stellation-res mailing list
> stellation-res@xxxxxxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/stellation-res

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