On Mon, 21 Jan 2002, Tim Bunce wrote:
>On Mon, Jan 21, 2002 at 01:42:40PM -0800, Jonathan Leffler wrote:
>> [...]
>
>Thanks, the examples helped explain where you're coming from.
>
>> [..] The default implementation of quoted_identifier will work with
>> DBD::Informix if the program has DELIMIDENT set when the connection
>> is made;
>
>Good.
>
>> it will break if DELIMIDENT is not set.
>
>Not so good, but easy to fix (to the extent possible) in the way
>I've previously described: Add your own quoted_identifier method
>that does no quoting if DELIMIDENT is not set.
Yes, but it also requires a new release of DBD::Informix to implement
it, and I don't know when I'll get the time to do that -- I have my
doubts about 2002 and I'm not sure about 2003 at the moment.
>> 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.
>
>To tell if the driver is going to quote identifiers from tables()
>an application can do:
>
> if ($dbh->quoted_indentifier('foo') eq '"foo"') { ... }
>
>and DBD::Informix is free to add it's own private attributes and/or
>versions of quoted_indentifier etc. to define whatever semantics it likes.
We have a horses and carts problem -- and I'm not sure which is the
horse and which is the cart, but you've got them the other way around
from me.
I was expecting the application to tell the driver whether it wants to
do quoting of identifiers -- because an application generally controls
the table names it uses, and if the table names it uses need to be
protected, then it needs to tell the driver to ensure that its names are
protected, whereas if the names do not need protecting, the driver need
do nothing.
It may be the difference between an application and a utility. Unto
some sort of first approximation, a utility has to deal with whatever
database exists, but an application controls what is in the database it
deals with.
>> 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.
>
>Any feel for how many applications may be using tables() with
>DELIMIDENT not set? (Yes, I know it's an impossible question :)
100% - essentially no-one ever uses DELIMIDENT, primarily because they
are sane. No-one who is sane uses DELIMIDENT. That's both 100% of the
applications written using DBD::Informix and 100% of those using the
tables function. However, the subset using the tables function is
probably a small subset of those using DBD::Informix. Based on what I
see in comp.databases.informix, I would be surprised if there are any
people using DELIMIDENT at all who have not been forced into it by some
application or application generator that insists on using delimited
identifiers. And there are not many people suffering from that, and
most of those seem to be running on Win32.
>I could grandfather in a hack to quoted_identifier so that, for
>DBD::Informix, it makes tables() behave like it does now for.
Is tables() provided by DBI or by DBD? I've forgotten... On average, I
prefer not to make DBI hack things, especially as at some point it would
have to be changed again if DBD::Informix caught up.
>> >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.
>
> $dbh->begin_work( { ix_foo => 'bar' } );
OK, probably. When does fetch get an attribute argument so we can
support scroll cursors?
>> 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})
>
>Er, I'm not sure what you're asking here, but for years the DBI->connect
>has basically done
> $dbh->{$_} = $attr->{$_} foreach keys %$attr;
>In other words all connect method attributes become handle attributes.
>Also the $attr is passed to the drivers connect method so that the
>attributes are available to the code that's making the connection.
OK. Is that information available in the login function of the driver?
IIRC, when I tried to get the information (back in 1996 or thereabouts),
it was not available when I made the connection to the database, but it
could be that I didn't understand how that bit of code was meant to be
written or how that bit of code should be used. I'm quite willing to
believe that the DBD::Informix connection startup code needs a complete
revamp -- it is amazing that it works. I didn't (and still don't)
understand which bits of magic are really necessary, and what does which
bit of it -- especially this far away from when I first did it. And, as
so often, once you kludge your way around something so it more or less
works, what you've got is adequate, and other things need fixing more,
so it doesn't get retrofixed. I know I sweated blood'n'tears over it
for the DBD::Informix 0.25 release, and could not make head or tail of
what the heck was going on and when anything useful was passed to me. I
still don't understand what the DBISTATE stuff does. I last spent a few
hours on this back in Aug 2001; prior to that, it was probably 1998 or
1999. Time has passed, and memories have faded.
If the hash is still not available to the login function, then please can
you work out what it would take to allow it to become available -- having
that information *before* making the database connection is *crucial* to
making it work sensibly -- at least for DBD::Informix.
Either that or I have to defer the real connection until after the
'login' function is over, so I can find out what I have to do to make
the real-login work correctly, which in turn means that the DBI->connect
would succeed when the user is not authorized to connect to the
database, or the database is non-existent, or whatever. The
alternatives are not good, anyway.
>> 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.
>
>You have them.
>
>> 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.
>
>Which has always been a core philosophy of the DBI.
Well, it has not always seemed like it to me -- AutoCommit being the
biggest bugaboo. But I'm willing to believe that it can be done and I
simply haven't had the energy to work out how the hell it can be done.
I certainly have never had the inclination to work out what the DBI
code actually does.
>> 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),
>
>The latest release of the DBI has a $dbh->get_info method to return
>that kind of info (as per the ODBC GetInfo function).
Mentioning that acronym is not designed to make me look kindly on
anything. However, I can probably get over that, too. And
DBD::Informix certainly hasn't been updated to deal with that -- it was
last released in March 2000, before the DBD book was released, and it
probably wasn't fully up to date with DBI even then.
--
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!"
