On 23.12.12 05:18, Darren Duncan wrote:
Jens Rehsack wrote:
Hi all,
I'd like to merge DBD::RAM into DBI for several reasons:
1) It's a tiny one without much dependencies, it should run fine
with just DBI::Sql::Nano (or should)
2) I had an evil idea how to allow Pure-Perl drivers can work
together in one instance like:
DBI->connect( "dbi:DBM:", , , {
sql_join_drv => "DBD::RAM", ... } );
But there is something for testing required ;)
3) It currently doesn't get some love, even if it should get.
Any comments?
Cheers
> I question this proposal.
>
> Does DBI currently have any useful drivers bundled, such that you could
> install just DBI and use it effectively for real work without installing
> any other drivers?
Yes, finally two: DBD::DBM and DBD::ExampleP;
> (I consider Proxy a special case, and even with it
> in use, the same question applies to whatever other DBI install is being
> proxied. And the other bundled driver-named classes seem to be more
> base classes than complete drivers.)
>
> I think it would be better for DBI to stick to defining an interface,
> and any implementations/drivers should be distributed separately.
>
> The only good exception I can think of is a driver bundled in order to
> bootstrap a more comprehensive DBI test suite that tests doing it for
> real, eg fetching or modifying of data, whatever the API defines rather
> than mocking. That ideally can then be reused with other DBI drivers.
That is the idea behind ;)
> So, I would only support bundling such a RAM-based DBMS if the DBI test
> suite exploits this in its test suite to help test the DBI interface
> itself.
Well, I do not tend to remove the bundled DBD::File and DBD::DBM once
we have a DBD::Mem. The reason is not only the test suite. People might
or might not rely on the availability of DBM::DBM in DBI, but bundling
them forces me to keep the dependencies minimal.
> -- Darren Duncan
Cheers
--
Jens Rehsack
