Re: Encoding for tables in DBD::File
On Tue, 01 Jun 2010 11:16:43 +, Jens Rehsack
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/
Re: Encoding for tables in DBD::File
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
Driver private functions, prefix and inheritance
Hi Tim, during the update of DBD::AnyData I hit some nice methods, which Jeff has added to it, e.g. ad_get_catalog, ad_mod_catalog and ad_clear. These methods modify the meta data of the tables managed by DBD::AnyData (DBD::AD) which will be done by DBD::File in future releases. So I talked with Merijn to move the methods into DBD::File to have them common for - DBD::AnyData - DBD::CSV - DBD::DBM - DBD::PO But now it comes ... typically driver private methods require a prefix. This prefix depends on the driver name (so ad_* for DBD::AD methods, csv_* for DBD::CSV methods etc.) - and it would be good for DBD::* users when we keep/support this behaviour. From this it follows that it's not done by moving the methods with some refactoring to DBD::File and install them by their name in DBD::File - there should be a better way. Any suggestions? Jens
Re: Encoding for tables in DBD::File
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.
