while hacking around in DBD::File and DBI::DBD::SqlEngine I stumbled
over a major design fault made in the past:
sub DBD::File::Table::get_table_meta () ... evaluates
$dbh->{f_meta}{$table}{initialized} and does something magic else. This
magic is fully DBD::File addicted (heavily relies on file2table) and it
should be broken into separate pieces to differ between initialisation
done for DBI::DBD::SqlEngine and DBD::File and DBD::DBM ...
I'd like to discuss it tomorrow in IRC (but I read my e-Mail if you have
comments at the evening).
If anyone else has ideas - please feel free to speak (but primary
restriction is backward compatibility to avoid breakage of dependent DBD's).
> while hacking around in DBD::File and DBI::DBD::SqlEngine I stumbled
> over a major design fault made in the past:
> sub DBD::File::Table::get_table_meta () ... evaluates
> $dbh->{f_meta}{$table}{initialized} and does something magic else. This
> magic is fully DBD::File addicted (heavily relies on file2table) and it
> should be broken into separate pieces to differ between initialisation
> done for DBI::DBD::SqlEngine and DBD::File and DBD::DBM ...
IIRC this was what you already advertised on your first round of
DBD::File internals redesign.
As long as "users" of DBD::File are not harmed, go ahead.
>> while hacking around in DBD::File and DBI::DBD::SqlEngine I stumbled
>> over a major design fault made in the past:
>> sub DBD::File::Table::get_table_meta () ... evaluates
>> $dbh->{f_meta}{$table}{initialized} and does something magic else. This
>> magic is fully DBD::File addicted (heavily relies on file2table) and it
>> should be broken into separate pieces to differ between initialisation
>> done for DBI::DBD::SqlEngine and DBD::File and DBD::DBM ...
> IIRC this was what you already advertised on your first round of
> DBD::File internals redesign.
Same place, different construction site ;)
> As long as "users" of DBD::File are not harmed, go ahead.
I have an idea which ensures that. I introduce table local getters and
use the "local" keyword as seen in App::Cmd ;)
> while hacking around in DBD::File and DBI::DBD::SqlEngine I stumbled
> over a major design fault made in the past:
Some - backward compatible - thoughts:
Replace all dir-related parts in DBD::File with callbacks
Make streaming interfaces able to override dir-related parts
Backward compatible AND extendable
> sub DBD::File::Table::get_table_meta () ... evaluates
> $dbh->{f_meta}{$table}{initialized} and does something magic else. This
> magic is fully DBD::File addicted (heavily relies on file2table) and it
> should be broken into separate pieces to differ between initialisation
> done for DBI::DBD::SqlEngine and DBD::File and DBD::DBM ...
> I'd like to discuss it tomorrow in IRC (but I read my e-Mail if you have
> comments at the evening).
> If anyone else has ideas - please feel free to speak (but primary
> restriction is backward compatibility to avoid breakage of dependent DBD's).
>> while hacking around in DBD::File and DBI::DBD::SqlEngine I stumbled
>> over a major design fault made in the past:
> Some - backward compatible - thoughts:
> Replace all dir-related parts in DBD::File with callbacks
> Make streaming interfaces able to override dir-related parts
> Backward compatible AND extendable
First shot attached as committed (svn revert for the win ^^).
Needs some additional tests for streams as well as pod updates.
>> sub DBD::File::Table::get_table_meta () ... evaluates
>> $dbh->{f_meta}{$table}{initialized} and does something magic else. This
>> magic is fully DBD::File addicted (heavily relies on file2table) and it
>> should be broken into separate pieces to differ between initialisation
>> done for DBI::DBD::SqlEngine and DBD::File and DBD::DBM ...
>> I'd like to discuss it tomorrow in IRC (but I read my e-Mail if you have
>> comments at the evening).
>> If anyone else has ideas - please feel free to speak (but primary
>> restriction is backward compatibility to avoid breakage of dependent DBD's).
