Re: Merging DBD::RAM into DBI

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