Re: Refactoring DBD::File in preparation for ReadOnly and streams ...

On 19.09.2012 17:50, H.Merijn Brand wrote:
> On Wed, 19 Sep 2012 17:21:32 +0200, Jens Rehsack <[email protected]>
> 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