On 22.12.12 19:01, Tim Bunce wrote:
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.
But unmaintained (and depreciated) drivers shall be avoided.
I also want avoid questions about the difference of DBD::RAM
and DBD::Mem.
I don't know and now I'm a bit confused ...
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.
Yes, I understand.
We should add some new CONFLICT drivers to DBI's Makefile.PL (not
motivated by forcing an update but inform people that their used
driver will stop working after updating to new DBI).
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.
If I understand you correctly, you're also against modifying the
behaviour of the old driver being incompatible to it's current
behaviour (and guide people relying on it to DBD::AnyData)?
Tim.
Cheers,
--
Jens Rehsack
