G
gabriele renzi
Hi gurus and nubys,
After the recent thread about XML GUIs and common apis, I thought
again about DB-API.
I mean: why do we have DBI?
I suppose it is perl's inheritage, but I wonder if we could better go
the way Python and Java do, with a formal DB API specification.
Let me explain it a little more:
Now, if you want to use a DBMS, you're chained to a different api for
every different binding. Or you can use DBI. BTW, here is what I think
is wrong with DBI:
one more level of possible bugs (not really much I think)
a casual user would need to download one more library.
Possible dependency/version hell ?
another choice in the API: ora-bindings api? postgres api? dbi api?
OTOH, the differences in the db bndings are often really little.
(well, apart from the difference in ths DBMSs themself).
For example, some may have ClassDB.conn or ClassDB.connect or
ClassDB.new to start a session on the DBMS.
And some other may have dbhandles.exec or dbhanler.execute..
But, in general, the apis are really replicating same concepts wth
different names.
java with JDBC and Python with DB API specification, OTOH, push the
dbms-bindings' developers to use a common api.
Obviously, if MyFavDB doesn't support triggers and stored procedures,
it won't support that part of the spec.
And if YourFavDB support a wonderful FeatureX that everyone else can't
support, You can add support for it and provide a proposal for a
standard api extension, so in future whoever writes a binding to
HisFavDB (that suport FeatureX too! wow, this must be killer stuff)
he would follow an existing path, not going raving in the jungle.
project lifeflow ATM (ther should be some crossroads, I'm omitting
them):
[developer]
choose if you want to be portable across dbms
choose if you want to use dbi
choose dbms
get dbms binding
get dbi binding
write code
distribute
[user]
get ProjectX
get dbi binding
get dbms binding
suggested flow:
[developer]
choose dbms
write code
distrubute
[user]
get ProjX
get dbms-binding
Actually, what I'm talking about is not again TIMTOWTDI.
TIMTWOTDI is about having different choiches, ATM we have just
different chains.
I'm proposing a 'refactoring' of the ruby-db relation in the whole.
IMVHO we could just 'port' DBI to the lower level, the binding one,
but I'm surely missing something.
Please forgive me if I'm wrong in many points and correct me in the
case.
What do you binding-developers, dbi-developers, and users think about
this ?
After the recent thread about XML GUIs and common apis, I thought
again about DB-API.
I mean: why do we have DBI?
I suppose it is perl's inheritage, but I wonder if we could better go
the way Python and Java do, with a formal DB API specification.
Let me explain it a little more:
Now, if you want to use a DBMS, you're chained to a different api for
every different binding. Or you can use DBI. BTW, here is what I think
is wrong with DBI:
one more level of possible bugs (not really much I think)
a casual user would need to download one more library.
Possible dependency/version hell ?
another choice in the API: ora-bindings api? postgres api? dbi api?
OTOH, the differences in the db bndings are often really little.
(well, apart from the difference in ths DBMSs themself).
For example, some may have ClassDB.conn or ClassDB.connect or
ClassDB.new to start a session on the DBMS.
And some other may have dbhandles.exec or dbhanler.execute..
But, in general, the apis are really replicating same concepts wth
different names.
java with JDBC and Python with DB API specification, OTOH, push the
dbms-bindings' developers to use a common api.
Obviously, if MyFavDB doesn't support triggers and stored procedures,
it won't support that part of the spec.
And if YourFavDB support a wonderful FeatureX that everyone else can't
support, You can add support for it and provide a proposal for a
standard api extension, so in future whoever writes a binding to
HisFavDB (that suport FeatureX too! wow, this must be killer stuff)
he would follow an existing path, not going raving in the jungle.
project lifeflow ATM (ther should be some crossroads, I'm omitting
them):
[developer]
choose if you want to be portable across dbms
choose if you want to use dbi
choose dbms
get dbms binding
get dbi binding
write code
distribute
[user]
get ProjectX
get dbi binding
get dbms binding
suggested flow:
[developer]
choose dbms
write code
distrubute
[user]
get ProjX
get dbms-binding
Actually, what I'm talking about is not again TIMTOWTDI.
TIMTWOTDI is about having different choiches, ATM we have just
different chains.
I'm proposing a 'refactoring' of the ruby-db relation in the whole.
IMVHO we could just 'port' DBI to the lower level, the binding one,
but I'm surely missing something.
Please forgive me if I'm wrong in many points and correct me in the
case.
What do you binding-developers, dbi-developers, and users think about
this ?