Re: Extract SQL-Engine basics from DBD::File

On 05/28/10 10:28, Tim Bunce wrote:
> On Thu, May 27, 2010 at 01:05:05PM +0200, H.Merijn Brand wrote:
>> On Thu, 27 May 2010 09:53:02 +0000, Jens Rehsack
>> <[email protected]>  wrote:

[...]
>> What I would like to see though, before we end up in quicksand, is to
>> first `finish' the f_meta work, so DBI would at least be releasable
>> again. Call me conservative, but that would make me happy.
>
> Agreed. Let's work towards a stable 1.612 release first.

Sure - but with our without the new base for Perl DBD's

>>> What I would like to see though, before we end up in quicksand, is to
>>> first `finish' the f_meta work, so DBI would at least be releasable
>>> again. Call me conservative, but that would make me happy.
>>
>> Sure, but I would favour a development release over a real release.
>
> To that end, I've just uploaded DBI-1.611_90.

/o\
As said in IRC, currently DBD::File still has some quirks. I try to
fix them today (I have to prepare an adventure for our Pen'n'Paper
RPG tomorrow, so I have to hurry ^^).

> (Also, can https://rt.cpan.org/Public/Bug/Display.html?id=56561
> be closed?)

I would be happy if daxim could provide a small test case for the bug.
I intend to say, it can be closed, but I'm not 100% sure.

>> I want to add some more test (DBD::File, DBD::DBM) and some documentation
>> how to implement DBD'S based on DBD::File as well as new DBD::SQLPerl.
>>
>> And I'd like to add a link to http://dbi.perl.org/support/ (section:
>> "CREATING A NEW DRIVER").
>
> That's great. Thanks. I'd like to make a release sometime next week.

Please wait a bit more for it. All Pure-Perl DBD's must be updated
and therefore they might need the new documentation. And I would feel
much better with many more tests and when I had the chance to update
DBD::AnyData and DBD::RAM, too.

> On Thu, May 27, 2010 at 12:35:59PM -0700, Darren Duncan wrote:
>>
>> I had already been thinking of this need for awhile, but in that
>> context it would have been a utility module, say with "common" in
>> its name or something.
>>
>> Unless there is already a precedent otherwise, I recommend leaving
>> the DBD::* namespace for actual DBI drivers, and utilities go in
>> some other namespace, though perhaps DBD::Util::* or something.
>
> I'd like to keep the DBD::* namespace reserved for actual drivers.

So DBD::File might be move, too?

> The DBI::DBD* and DBI::DBD::* namespaces would be suitable.
> Perhaps DBI::DBD::PerlBase (for 'perl base class').
>
>> The choice may also be affected by whether the new module is meant
>> to be subclassed by a DBI module or just "used" ... the latter makes
>> more sense if it would be used by multiple component classes like
>> the driver and statement handles, unless the utility has one for
>> each of those, but I wouldn't make it a subclassing situation.
>
> Certainly the import/mixin vs subclass aspect of the design needs
> some exploration. There might be a role for both a DBI::DBD::PerlBase
> class plus a DBI::DBD::Utilities module.

Sound like a great idea.

Jens