Brian Candler wrote:
On Wed, Jul 14, 2004 at 11:35:51AM +0200, Michael Neumann wrote:
require_gem 'dbd-pg', '> 1.0'
db = DBI::DBD::Pg::Driver.connect(...)
# now the same interface as DBI,
# but methods are send directly to the "DBD"
db.execute(...)
OK, although that means there's no common functionality in the DBI layer;
it's all implemented in the DBD. I have no problem with that, as long as it
is adequately defined (to ensure consistency) and unit tested.
right.
You can still have a single 'connect' interface to this, of course:
exactly. there will be a DBI compat layer.
def DBI::DBD.connect(*src)
case src[0]
when /\Adbi:pg:/i
return DBI::DBD::Pg::Driver.connect(*src)
when /\Adbi:sqlite:/i
return DBI::DBD::Sqlite::Driver.connect(*src)
..
else
raise "Unknown database type #{src[0].inspect}"
end
end
And I still think it's worth having a common base class (DBI::DBD) which the
other ones are derived from. This allows you to add your own methods to the
bass class which are available to all DBDs.
of course there will be base classes: DBI::BaseDriver, DBI::BaseDatabase
and DBI::BaseStatement
The "Ruby DB API" DBDs depend on the DBI for common code, like
DBI::Binary, DBI::Timestamp etc. or for a default implementation of
"insert" and so on. But they could live without the DBI.
Equivalently, you might as well get rid of DBI entirely, and just have
DBD::Binary, DBD::Timestamp etc.
I don't like it. DBI is a collection of database independent helper
methods for use by the DBDs. Of course, each DBD is free to return it's
own e.g. DBD::Pg::Binary object instead of the standard DBI::Binary one.
alternatively (in future DBI NG):
db.prepare("INSERT INTO ....") do |sth|
sth.execute_many(values)
end
That's interesting, but are there any other SQL statements other than INSERT
which could benefit from this?
I can't think of any (at the momment) :-)
Regards,
Michael
|
