Re: Merging DBD::RAM into DBI

On Sat, Dec 22, 2012 at 03:02:06PM +0100, Jens Rehsack wrote:
> On 22.12.12 10:28, Tim Bunce wrote:
> >On Sat, Dec 22, 2012 at 12:06:57AM +0100, Jens Rehsack wrote:
> >>On 21.12.12 22:41, Sven Dowideit wrote:
> >>
> >>But I mean the base DBD::RAM you'll find at
> >>http://search.cpan.org/dist/DBD-RAM/ ;)
> >>
> >>I would reduce it for in-memory tables only.
> >
> >You didn't mention that earlier :)
> 
> Sorry, my fault. I decided that long time ago (when I introduced
> DBI::DBD:SqlEngine )but didn't find a tuit. Because of DMD::RAM
> is predecessor of DBD::AnyData, there is no treason to keep it in
> a disfunction way.
> 
> >Hacking on DBD::RAM means creating an incompatible version.
> >Someone somewhere may be using it.
> 
> Doesn't look like. I see regular DBD::AnyData RT's, but no
> DBD::RAM RT's.

Sadly that's not a reliable indicator.

> >Why not write a new driver, say DBD::Mem, to be small/clean/fast from
> >the start?
> 
> I'd prefer to recycle the existing namespace - to avoid overpolluting CPAN.

CPAN names are not a limited resource.

> We can do a two-step thing: first I rewrite it to RAM tables and
> upload the new version. Second step is merge into DBI.

Merging into the DBI would force an old DBD::RAM to be upgraded when
people upgrade to the DBI that has a new one bundled.

Let me put it this way: I'm much more likely to bundle a new small
module than to bundle an incompatible version of an old one.

Tim.