current DBD::AnyData will be broken when releasing next DBI

[Jens Rehsack]

Hi,

as some people from #dbi channel on irc.perl.org know, I'm currently
working on updating
DBD::AnyData to work properly with recent DBD::File updates.

AnyData and DBD::AnyData were born in year 2000 - and the design
didn't changed since birth.
But DBD::File got some rework - thanks to Tux (H. Merijn Brand), mje
(Martin Evans) and myself.
The further development of SQL::Statement brakes at least DBD::DBM -
so we did some
refactoring (and test extension) to detect such breakage earlier next time.

Without blaming anyone: AnyData implements the whole DBD::File (state
of yr 2000) and
DBD::AnyData is more or less misusing the DBD::File infrastructure to
provide an DBI
interface to AnyData.

My current intention is to rework AnyData and DBD::AnyData to have
clear responsibility
which tasks are done at which place in the code. This is somewhat
difficult, because there
are no use cases or tests for AnyData (or DBD::AnyData) giving full
study-able examples.

I decided to reduce the functionality of AnyData - to have a module
which finally does exactly
what is required - without providing helper functions for a dozen of
foreign modules. But this
is more difficult than expected:

AnyData provides remote file access (which must be provided by
DBD::File, too when we
want to keep all functionality). AnyData mixes a lot of functionality
and re-implements a lot
which is already provided by other modules.

This leads me finally to go just one more step back: I should define
responsibilities in AnyData
(keeping DBD::AnyData and DBD::File in mind) for the parser modules,
for the storage modules
and for the controller. I think, the adTie (), adTable () functions
provide some kind of views -
something which should be provided from somewhere else - not from the
AnyData.pm itself.
Further, I think, either the storage represented by DBD::File::Table
should be usable by AnyData
(maybe DBD::AnyData could provide an adapter) or DBD::File should be
able to use pluggable
storage backends, too.

Of course, another way could be to extract the SQL-engine interface
from DBD::File into
a DBI::DBD::SqlEngine and DBD::AnyData uses that without caring of
DBD::File (for some
time until we could do better).

I have some additional tasks to do where I need to write some more
modules and update
some of those I currently have. And I have a time limit for that tasks
which means, I can't play
for month with DBD::AnyData.

That's why I ask: would it be very bad when DBI-1.612 would break
DBD::AnyData for a limited
amount of month (3-5) or should I (we?) investigate more effort to get
a clean, running
AnyData and DBD::AnyData out there with DBI-1.612?

Best,
Jens

Re: current DBD::AnyData will be broken when releasing next DBI

[Tim Bunce]

On Wed, Jun 23, 2010 at 04:18:27PM +0200, Jens Rehsack wrote:
 
 Of course, another way could be to extract the SQL-engine interface
 from DBD::File into a DBI::DBD::SqlEngine and DBD::AnyData uses that
 without caring of DBD::File (for some time until we could do better).

 That's why I ask: would it be very bad when DBI-1.612 would break
 DBD::AnyData for a limited amount of month (3-5) or should I (we?)
 investigate more effort to get a clean, running AnyData and
 DBD::AnyData out there with DBI-1.612?

Rather than trying to get a clean DBD::AnyData, how about we aim for a
dirty one instead?

DBD::AnyData says use base qw( DBD::File );. The DBD::File that
shipped with DBI 1.611 could be copied into the DBD::AnyData distro
and renamed to DBD::AnyOldFile (and hacked internally to match).
Then DBD::AnyData could say use base qw( DBD::AnyOldFile );

Not pretty, or clean, but possibly the basis of a workable solution?

Tim.

Re: current DBD::AnyData will be broken when releasing next DBI

[Jens Rehsack]

2010/6/23 Tim Bunce tim.bu...@pobox.com:
 On Wed, Jun 23, 2010 at 04:18:27PM +0200, Jens Rehsack wrote:

 Of course, another way could be to extract the SQL-engine interface
 from DBD::File into a DBI::DBD::SqlEngine and DBD::AnyData uses that
 without caring of DBD::File (for some time until we could do better).

 That's why I ask: would it be very bad when DBI-1.612 would break
 DBD::AnyData for a limited amount of month (3-5) or should I (we?)
 investigate more effort to get a clean, running AnyData and
 DBD::AnyData out there with DBI-1.612?

 Rather than trying to get a clean DBD::AnyData, how about we aim for a
 dirty one instead?

 DBD::AnyData says use base qw( DBD::File );. The DBD::File that
 shipped with DBI 1.611 could be copied into the DBD::AnyData distro
 and renamed to DBD::AnyOldFile (and hacked internally to match).
 Then DBD::AnyData could say use base qw( DBD::AnyOldFile );

 Not pretty, or clean, but possibly the basis of a workable solution?

That would be the DBI::DBD::SqlEngine (what is more or less the only
real dependency).
And this module is required for the next version of DBD::Sys, too.

Jens