On Mon, Dec 02, 2002 at 05:14:14PM +0100, Henrik Tougaard wrote:
I'm resuscitating this old email in view of the releases of DBI 1.33 and 1.34. Since I did most of the work on DBD.pm (DBI::DBD), I need ensure that I either did get all the salient information from this email and any others into the DBD.pm file, or beg someone to provide appropriate patches. I don't much mind whether the patches are sent to Tim or to me or to btoh of us, or to dbi-dev too -- we'll coordinate something, somehow.
Are there any other changes in that documentation - or additions where the documentation is simply missing - that anybody has? Again, if so, please send them to Tim/me/dbi-dev.
I am in the (long drawn) process of migrating DBD::Ingres from embedded SQL to the vendor supplied API. This leads me to read
both the docs and the code in DBI with great enthusiasm, but also
raises some questions:
1) preparse.
It is still undocumented (mu quess: patches welcome), but I assume that it is ready for use - especially as it has been included in the test suite.
Is that correct? ie. that the interface is stable (or as stable as we can expect it to be).
No, sadly.
DBD::Informix has to use its own version of preparse(); the 'standard' version is too non-Informix-compliant to be readily usable. And the Informix version has some really nasty gotchas in it which makes it of limited value to others - except perhaps as an interesting exercise.
Did anybody else notice that SQL-99 adds /* c-style */ comments to the -- double-dash to end of line comments in SQL-92?
I would like to add a format (or maybe two) to the function. Ingres uses '~V' (yes: a tilde followed by a capital letter V) as a placeholdermarker, and '$n = ~V' for repeated queries (where the 'n' is a sequence number from 0 and up). Patches wellcome I assume...
The "big question" is whether to continue down the current path of a pure-C implementation or to change it to a pure-perl implementation (perhaps with a C version for greater speed).
I expect the functionality offered by preparse (esp ODBC escape sequences) to become very important over time and thus DBI::PurePerl would be very limited without it. So a pure-perl implementation will be needed sometime.
I'm still in two minds about that.
Scott Hildreth has been working on it from time to time for me. He's looking into a Parse::RecDecent implementation now.
2) fetchall_arrayref.
The code in Driver_xst.h for fetchall_arrayref seems to be a stub for something to come. I would love to be able to 'get my fingers on' fetchall_arrayref as the Ingres API has methods for returning all rows from a select without involving a cursor - and sligthly faster than a cursor open as well!
Ah, what's needed there is very simple - I mentioned it a week or two ago... All the methods in Driver.xst should have #ifdef dbd_foo around them, where dbd_foo if the name of the underlying implementation function in your driver code.
See the rows method for the one (and I think) only example currently in Driver.xst.
For fetchall_arrayref (and some like it) instead of just an #ifdef it needs a #else part that'll contain the current code.
3) dbd_db_do
is referenced several places: DBD.pm and dbd_xsh.h (and in both the Oracle and ODBC drivers), but all I can find is the declaration - the function and any call to it seems to be missing. Not that I'll miss it, but it does confuse things...
Something like this:
#ifdef dbd_db_do
void
do(dbh)
SV * dbh
CODE:
D_imp_dbh(dbh);
... etc ...
#endif
is missing from Driver.xst.
4) STORE_attrib_k and FETCH_attrib_k
are only declared in dbd_xsh.h, but are not defined/used anywhere. Are they reserved for future use or???
Kind of. Vauge ideas (related to hashing attribute names to speed up lookup etc) that never got very far, partly because get_info took a different, better, direction. You can ignore them.
5) DBIS and DBILOGFP
The latest Changes states:
Changes for driver authors, not required but strongly recommended:
Change DBIS to DBIc_DBISTATE(imp_xxh) [or imp_dbh, imp_sth etc]
Change DBILOGFP to DBIc_LOGPIO(imp_xxh) [or imp_dbh, imp_sth etc]
Any function from which all instances of DBIS and DBILOGFP are
removed can also have dPERLINTERP removed (a good thing).
I must have blinked at some time. This is the first time I have noticed 'dPERLINTERP' - it is nowhere in the old DBD::Ingres (will that cause things to fail so that I should hurry and put it in, or can I relax and leave things as they are?).
Leave them as they are and tell anyone who uses perl 5.005 threads to upgrade.
I have changed all references as given above, but could we please have a shorthand for the debug output, as it does look a bit longwinded to write:
if (DBIc_DBISTATE(imp_sth)->debug >= 5)
PerlIO_printf(DBIc_LOGPIO(imp_sth), ....);
all over the place.
That could be
if (DBIc_DEBUGIV(imp_sth) >= 5) ...
which is a _little_ better :) Though actually that doesn't do quite the right thing. I'll either add a new macro or change that one (or what it refers to) to do-the-right-thing.
Something like: DBI_DEBUG(imp_sth, 5, ....); would be nice - yes I know: patches....
Doing vararg macros with portable C is a bit tricky. I'd like to make that a call back into DBI internals. Maybe something like:
if (DBIc_DEBUGIV(imp_sth) >= 5) DBI_TRACE(imp_sth)(...);
6) DBIh_EVENTx
are to be removed. The macroes do nothing now as far as I can see.
This leads me to wonder how can I signal an error now? The DBD.pm states eg under dbd_db_STORE:
The return value is TRUE, if you have handled the
attribute or FALSE otherwise. If you are handling an
attribute and something fails, you should call do_error,
so DBI can raise exceptions, if desired. If do_error
returns, however, you have a problem: The user will never
know about the error, because he typically will not check
"$dbh->errstr".
'do_error' records the error in err and friends and then calls DBIh_EVENT2 to get the error handled. This is not done now (perhaps has never been done).
May have been 'done', but never 'did' anything much :)
As far as I can discover the errorchecking is done when the driver returns to the DBI-layer, then the DBI dispatcher checks DBI->err and handles the error if any.
Am I correct?
Yes.
So a patch for DBD.pm would seemingly be welcome....
Of course! :) [There's lots that's out of date or incomplete. All driver authors are encouraged to trip over parts and send in a patch when they pick themselves up ;-]
All in all it is quite fun to be redoing the driver implementation. The DBI has become a lot friendlier since I did it last (or is it just that I know a lot more about what is going on... hmmm), so the progress is not quite as slow as I feared ;-)
:)
It's my intention that the DBI provide more 'hand-holding' for drivers over time as part of a (very) vague perl6 migration strategy.
Tim.
--
Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) #include <disclaimer.h>
Guardian of DBD::Informix 1.04.PC1 -- http://dbi.perl.org/
