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.
