On Tue, 01 Jun 2010 11:16:43 +0000, Jens Rehsack <rehs...@googlemail.com> wrote:
> 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? Actually I have not really formed a strong opinion to weather the current or the new situation is better. I can imagine good use for both. The fact that I ran into it, just exposed a new behaviour I/we never really discussed. I'm certainly *NOT* suggesting new flags to keep old/other behaviour. OTOH, new centralized methods might (or might not) reveal functionality to alter enconding (by force) between close and open. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/