[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [stellation-res] Yet another DB abstraction idea...
|
On Wed, 2002-08-14 at 11:53, Mark C. Chu-Carroll wrote:
> Notice the swap of the field name and the field type. The template has a
> fixed position for each word and if we replace $INT with INTEGER we get
> a statement that fails.
This is actually an example of the kind of confusion that I worry about. We
abstracted things partially in our current code, so that I haven't typed the
raw SQL in a while. I got the order wrong. *No* database will take what
I gave. (And no one noticed it until now! :-) )
I use SQL a lot more than Java in my daily work. Hard to let it pass unnoticed. ;)
I'm not sure whether that's an argument in favor of saying "SQL DDL syntax
is so arbitrary and so arcane that we shouldn't muck with it explicitly", or
"Too much abstraction creates enough distance to breed confusion".
Not so arbitrary or arcane, but we still need a little bit of abstraction. Oracle couldn't manage VARCHAR(4000) and it's a mayor database.
> Also, the template missed to represent the NOT NULL clauses that are
> necessary to build a primary index in the Firebird/InterBase example.
Same goes for Postgres and DB2. I was just lazy about the typing. Personally,
I try, whenever possible, to have all column types include "NOT NULL".
> Other databases require the field name between quotes ( i.e.: "aid"
> INTEGER ), so the template would fail again.
Out of curiosity: which ones?
Firebird or InterBase can distinguish between uppercase and lowercase field names by using quotes. You can leave quotes off if you want only uppercase field names. It's safer to use quotes at table creation time.
I'm still sort of sitting on the fence. In theory, I kind of like the abstract
factory approach. But each time I try writing out the table construction
code for a factory approach, it just feels overwrought - too heavyweight.
The template approach has less design elegance. But it's got the advantages of
brevity, and concreteness. So in practice, I lean towards the templates.
I also think we might be spending more time than this is really worth. It
might be time to try some coding. I'm going to implement the template
approach. If you have time, try putting together at least a sketched
implementation of the factory approach with a Firebird implementation.
Then I'll write the intrinsic tables in both approaches, and we can
really gauge what seems better in the code.
I will try to write a class that handles table creation tonight. Don't hold your breath, I have a lot of work to do right now to keep on schedule :( .
Rodolfo
--
MAXPROGRAMS
IBM Business Partner
Microsoft MSDN Business Connection Partner
rmraya@xxxxxxxxxxxxxxx
http://www.maxprograms.com
|
