On 06/01/10 10:42, Tim Bunce wrote:
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.
Well, I think Merijn wants to point to the situation, that the behaviour
has changed. In DBI 1.611 f_encoding wasn't sticky, in DBI 1.612 it will
be. Maybe he asks indirect about a flag like f_keepoldbehaviour which will
update the f_encoding in the meta data, when it has changed globally?
Jens
