On Sun, May 30, 2010 at 12:33:44PM +0200, H.Merijn Brand wrote:
> In DBI-1.611 I introduced f_encoding for tables. That works great.
>
> In 1.611, f_encoding was evaluated from the database handle each time a
> table (file) was opened, so
>
> my $dbh = DBI->connect ("dbi:File:");
>
> $dbh->{f_encoding} = undef; # raw mode
> my $sta = $dbh->prepare ("select * from foo");
>
> $dbh->{f_encoding} = "utf-8"; # Unicode UTF-8
> my $stb = $dbh->prepare ("select * from foo");
>
> works as this coder would expect: $sta opened table foo in raw mode,
> whereas $stb open THE SAME table in utf-8 encoding.
>
>
> Now with the rework for DBD::File, the meta-info for a table is stored
> only once, on first opening of the table. This is to ensure being able
> to follow ANSI SQL in case preserving/ignoring issues, which IMHO is a
> good thing.
>
> On the one hand, the code in 1.611 could be considered more DWIM than
> the current state, but on the other, something could be said for the
> new situation too: it is insane to have two concurrent handles on the
> same file in two different encodings.
>
> OTOH, it is imaginable that when I CLOSE a handle to a table and open
> it again, now in different encoding, that action is completely legit.
>
> That would mean we'd have to change a few innards to enable resetting
> some previous gained knowledge about tables OR flag a table being
> closed, and re-evaluate flags like f_encoding when the table is opened
> again.
[I'm not sure I understand the situation, but ...]
it seems reasonable for the encoding of a table to be sticky,
which implies some kind of cache in the $dbh.
Tim.
