Re: [stellation-res] Yet another DB abstraction idea...

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

Sorry about the previous empty message... I use a rather funky keyboard at 
work, due to RSI trouble. When switching between the laptop at home, and
the funky thing at work, I trip up. It's really easy to accidentally hit 
control-return on this keyboard, which send the message in my mailer.

Anyway... On to the content that I wanted to comment on:

On Wednesday 14 August 2002 04:43 pm, Rodolfo M. Raya wrote:
> In my previous message I omitted some things:
>
> * There should be a DTD (maybe a schema) to follow when writing the XML
> specification for the table. If we create a DTD that is simple enough,
> creating documents will be easy too.
>
> * The XML document can be generated in memory as DOM object and passed
> to an XSLT tool like Xalan, so nobody has to read it (it doesn't matter
> if it has 6 or 38 lines).
>
> * We can hide the XML document creation behind a class. If we create a
> class that can be serialized as XML DOM the code might look like:
>
>
>     Table table = new Table( "Properties" );
>     table.addField( "aid", "INTEGER");
>     ...
>     table addField( "name","VARCHAR(2000)");
>
>     String fields[] = {"aid","vid"};
>
>     table.addPrimaryKey( fields }
>     table.addForeignKey( "fk3","versions",fields); // (name, referenced
>     table, fields)
>
>     org.w3c.dom.Document doc = table.generateDOM();
>
>
> Transform doc using any XSLT tool and generate the right SQL
> statement(s) to execute.

Looking at this, my big question is, why bother with the XML at all?

If you're going to use an object to represent the table declaration, and 
you're going to generate the table programatically off of an abstract 
representation of the declaration... Why bother passing through XML? Why
create an object, populate it, translate in into XML, and run an XSL 
transformation? It seems very roundabout.

*If* we want to go the more abstract route, I'd prefer to just take the code 
you have above, and replace the "table.generateDOM()" with 
"table.generateSQL()". Am I missing something here?

I also find myself leaning away from this approach in favor of the templates 
I proposed earlier today, because we're expecting people to use SQL
directly everywhere else; making the DDL stuff so abstract just makes things
confusing. 

I was looking over some of our current DDL, which uses an early attempt at 
SQL parameterization, and while I thought it was really neat when we first 
added it, now I look at the table creation code, and find it difficult to 
read and manipulate, because it's so hard to see the actual SQL amidst the
parameterization noise.  

It's certainly arguable that the halfway method that we used in the current 
DBAcessPoint is particularly awkward, because it abstracts parts of the SQL 
while leaving it explicit that we're doing string assembly, and that a fuller 
abstraction will be clearer.

My big question is: what do we get out of going full bore on the abstraction, 
compared to the template method I used above?

The only thing that I can see is that we could automatically execute the 
constraints separately from the table construction. That's nice. But I don't
think it's quite enough to justify the increase in complexity.

	-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