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
<rehs...@googlemail.com> 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
