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: > > > Hi developers, > > > > during refactoring of DBD::File and new wishes (e.g. SQL_IDENTIFIER_CASE > > from Martin Evans, getinfo() support, ...) and my own try of a pure-perl > > DBD for system tables (DBD::Sys) I see many common code. > > > > I would like to extract the common code into a base class DBD - maybe > > named DBD::SQLPerl (placed SQL in from for private methods and attributes > > naming - the should have the prefix "sql_"). > > > > I know at least two additional DBD's which could benefit from that: > > - DBD::Google from Darren Chamberlain (I don't know if he is subscribed > > to dbi-dev@perl.org) > > - DBD::Sys from me > > > > If there are more, it would be great to know about them. > > I do have no objections to refactoring common code into a new module. > I've got no opinion (yet) for the name(space) of that module. > > 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. On Thu, May 27, 2010 at 12:01:39PM +0000, Jens Rehsack 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. > > Sure, but I would favour a development release over a real release. To that end, I've just uploaded DBI-1.611_90. (Also, can https://rt.cpan.org/Public/Bug/Display.html?id=56561 be closed?) > 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. 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. 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. Tim.
