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/
