With a common api Joe just download a binding, find an already common
and documented interface, and start coding.
Then if he want to switch to DBMS-bar he could have (potentially)
working code without the need for changes.
DBI is that common interface (and is modelled on the Perl DBI … I suspect
Python’s is likewise modelled on Perls). DBI comes with a set of drivers
(DBDs) for each type of database supported. The DBDs each talk to the
native C API library to access the actual database. I think you are
advocating merging the DBD and the native library into one entity, but I’m
not sure what that would accomplish. Perhaps it is more of a packaging
issue rather than a code issue.
DBI is that common interface (and is modelled on the Perl DBI … I suspect
Python’s is likewise modelled on Perls).
right. but every dbms binding has a different basic api. Why this
useless duplication?
(Probably that may be useful, and I’m just too stupid to understand
why)
DBI comes with a set of drivers
(DBDs) for each type of database supported. The DBDs each talk to the
native C API library to access the actual database. I think you are
advocating merging the DBD and the native library into one entity, but I’m
not sure what that would accomplish.
I’m pushing the elimination of a level of indirection.
Why a wrapper library(an additional pkg, additional version
matching, distribution pains, api to learn, maybe slowness cause dbi
is pure ruby) + a native library, if we could have just native
libraries?
When you have stuff that you may simplify you refactor, am I right?
Perhaps it is more of a packaging
issue rather than a code issue.
Having RubyGems + CPAN-like archive (RubyGemMine?) may hide the
problem, I really agree (and I don’t mind if it’s just hidden)
BTW, thanks for the answers, I’m really curious about the community
ideas on this subject
···
il Sat, 10 Jan 2004 07:18:53 +0900, “Weirich, James” James.Weirich@FMR.COM ha scritto::
DBI is that common interface (and is modelled on the Perl DBI … I
suspect
Python’s is likewise modelled on Perls).
right. but every dbms binding has a different basic api. Why this
useless duplication?
(Probably that may be useful, and I’m just too stupid to understand
why)
Just for connecting etc. The querying part is identical. Typically you
would centralize the connection creation code and have querying etc.
somewhere else where you just hand over a live connection. Then you can
exchange the dbs as easily as possible (i.e. SQL syntax issues for
specialized queries still have to be changed, but basic CRUD operations
will work without change). IMHO it is not feasible to build a unified DB
API. JDBC goes quite far but not much further than DBI: the only parts
where JDBC is better with respect to a unified API is the definition of
certain escape sequences for data and time formats and stored procedure
invocation among some others.
See here for the JDBS style escaping:
DBI comes with a set of drivers
(DBDs) for each type of database supported. The DBDs each talk to the
native C API library to access the actual database. I think you are
advocating merging the DBD and the native library into one entity, but
I’m
not sure what that would accomplish.
I’m pushing the elimination of a level of indirection.
Why a wrapper library(an additional pkg, additional version
matching, distribution pains, api to learn, maybe slowness cause dbi
is pure ruby) + a native library, if we could have just native
libraries?
I don’t know what wrapper you are talking about. One level of wrapping
(i.e. what DBI does) is appropriate and nicely to use.
When you have stuff that you may simplify you refactor, am I right?
Of course.
Regards
robert
···
il Sat, 10 Jan 2004 07:18:53 +0900, “Weirich, James” > James.Weirich@FMR.COM ha scritto::
