On 19.09.2012 17:50, H.Merijn Brand wrote:
> On Wed, 19 Sep 2012 17:21:32 +0200, Jens Rehsack <rehs...@cpan.org>
> wrote:
>
>> Hi Merijn,
>>
>> 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 ;)
> I do not want a truckload of code like
> http://repo.or.cz/w/DBD-CSV.git/blob/8d7f4284:/lib/DBD/CSV.pm#l90
No one wants that - and I think meanwhile you can increase the
prerequisite of DBI version to remove some of that truckload ...
> which has now been removed as the prereq's are higher:
>
> PREREQ_PM => {
> "DBI" => 1.614,
> "DBD::File" => 0.40,
> "Text::CSV_XS" => 0.91,
> "SQL::Statement" => 1.33,
> "Test::More" => 0.90,
> "Encode" => 0,
> "charnames" => 0,
> },
>
> But in future upgrades/updates, code like that is not unlikely to
> re-appear
Well, business as usual ;)
/Jens
