On Mon, 21 Jan 2002, Tim Bunce wrote:
>On Mon, Jan 21, 2002 at 11:17:36AM -0800, Jonathan Leffler wrote:
>> On Sun, 20 Jan 2002, Tim Bunce wrote:
>> >On Mon, Jan 14, 2002 at 09:58:51AM +0000, Simon Oliver wrote:
>> >> > [...]
>> >> [...]
>> >[...]
>> [...]
>[...]
>
>The argument with quote_identifier is that something like this:
>
> $sth = $dbh->table_info(undef, "%", "%", "TABLE");
> while ( my ($c, $s, $t) = $sth->fetchrow_array ) {
> my $table = $dbh->quote_identifier($c, $s, $t);
> my $count = $dbh->selectrow_array("select count(*) from $table");
> print "Table $_ has $count rows\n";
> }
>
>should work reliably.
And I'm trying to tell you that I think that DBD::Informix cannot make
this work reliably without a priori (connect time) information that you
want to do it. I'm not about to break my existing users code in order
to make a new piece of DBI work, and the necessary change to make this
stuff work reliably will break existing working (though not necessarily
portable) code!
>And, by extension, so should this:
>
> foreach ($dbh->tables) {
> my $count = $dbh->selectrow_array("select count(*) from $_");
> print "Table $_ has $count rows\n";
> }
This seems obvious, up to a point. But my point is that UserA can
create tables in an Informix database that UserB cannot access, not
because of GRANT/REVOKE privileges, but because UserA has an environment
variable set that UserB does not. Since you've refused to provide us
with the information at DBI->connect() time, if UserB runs the DBI
application, then UserB is going to get breakages because UserA has
carefully sabotaged any possibility that DBD::Informix can protect UserB
from his handiwork. Further, even if the table names are OK for UserB
to reference, some of the column names may not be referencable, which
makes the necessary queries on the system catalog to determine which of
the tables that exist can be referenced by the current user extremely
painful to write -- they are already painful, but this makes it so much
worse.
So, I feel painted into a corner. I'm basically going to have to ignore
the whole thing, and people who want DBI to work with Informix are going
to have to know enough about how Informix works to make their
application correct.
I strongly recommend closing this conversation now. I've made all the
points I can make as clearly as I can make them, and I'm not having any
effect on the discussion. I don't have time to work out how to
reiterate differently what I've said previously. The default
implementation of quoted_identifier will work with DBD::Informix if the
program has DELIMIDENT set when the connection is made; it will break if
DELIMIDENT is not set. Since DBI won't allow the application to tell us
that it wants to use quoted identifiers, we're stuck in a lose-lose
situation. It is all a bit academic; I don't really have time to do
anything significant to DBD::Informix anyway -- it will limp along as it
has for the last two years.
>> However, DBD::Informix will go along with whatever DBI decides. Most
>> probably, it simply let DBI do its stuff and not override the default
>> method. If it doesn't work, it is the application's problem - with or
>> without use of quoted_identifier. Just the same as it is now, without
>> the quoted_identifier method. The default quoted_identifier will make
>> the correct transformation for Informix; the result may not be usable,
>> or it may be usable but yield the wrong result, but both those can
>> happen whether or not quoted_identifier is called.
>>
>> AFAIAC, this is another case of DBI trying to do too much
>
>I must be missing something here. Can you express the issue in terms
>of the two examples I've given above?
>
>> AutoCommit is the other prime example.
>
>If there's a problem with the (recently added) $dbh->begin_work method
>then please feel free to start up a new thread.
Informix has extensions to BEGIN WORK, such as BEGIN WORK WITHOUT
REPLICATION, which I abhor but which DBD::Informix needs to be able to
support. I wasn't aware of this when we spoke in Monterety,
incidentally, but it adds to the extent of the problems with AutoCommit.
AutoCommit screws me up all ways, and this is particularly painful. And
it is particularly bad since we don't have database-dependent connection
attributes AFAICT -- stuff such as:
DBI->connect($dbid,$user,$pass,{db_attribute=>1})
With support for those, I could (and would) allow informed users of
DBD::Informix to override the DBI defaults that make life hell for
everyone using Informix databases. The innocent application writer who
is given an Informix database would still get DBI-compliant behaviour,
but those needing native behaviour would be able to get it.
Since I've had no success converting people to my viewpoint starting
from the days when AutoCommit was first mooted, despite extensive
kilobytes of discussion, I have no intention whatsoever of reopening the
discussion. My previous comments all still apply. IMNSHO, the idea of
DBI imposing AutoCommit is, and always was, misguided. DBI should
provide a mechanism that allows the DBD to describe the native semantics
of the database (no transactions, implicit transactions, explicit
transactions, whatever; these days, we should be reviewing whether
savepoint and rollback to savepoint are supported), rather than making
DBD writers jump through hoops to make their database servers perform
unnatural acts without a connect-time get-out clause that lets the user
say "behave naturally; ignore the DBI imposed semantics". Adding
AutoCommit support to DBD::Informix made it vastly bigger than it should
be -- it is horrendously hairy to do remotely properly, and I'm not sure
I've got it right even now. And there are things that I should be able
to do that it prohibits me from doing. If you need to see more details
of my views, go to the archives. They are (or should be) copious.
Or we need to find someone else who can manage a more flexible mindset
to maintain DBD::Informix for the DBI community -- volunteers very
welcome.
The subject of AutoCommit is closed again as of now.
--
Jonathan Leffler #include <disclaimer.h>
STSM, IBM Data Management Solutions. Phone: +1 650-926-6921
Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Guardian of DBD::Informix v1.00.PC1 -- http://dbi.perl.org
"I don't suffer from insanity; I enjoy every minute of it!"
