On Thu 21 Nov 2002 03:20, David Wheeler <[EMAIL PROTECTED]> wrote:
> On Wednesday, November 20, 2002, at 04:51 AM, H.Merijn Brand wrote:
>
> > I've added a driver specific verbose setting to be able to see driver
> > specific
> > debugging. IIRC, Tim didn't agree with the name, so I have to change it
> > sometime, but - certainly in the development phase - it might be very
> > handy to
> > skip the DBI debug, and only see the driver specific dubugging
> >
> > my $dbh = DBI->connect (....);
> > $dbh->{DBDverbose} = 9;
> >
> > is what I have currently implemented in DBD::Unify
> > where the highest of this internal verbosity level or DBI's trace
> > level is
> > used for reporting. Again, this internal level is probably only
> > usefule for
> > people that are conbcerned with the specific DBD implementation (like
> > you are),
> > and not the end user.
>
> Right. I think I'd be more likely to add use ifdefs or a macro or
> something during development...
#ifdef's tend to get stuck on `true' :)
Once you start, you will see that the driver will never be /finished/. Either
you have to add features, after yet another DBI enhancement, or you have to
change the interface calls because the binding libraries change, or some end
user has found a way to crash your driver using some weird undocumented
feature or ...
End of the line is that external controlable debug behaviour turns out to be
much more useful than ifdef's. And you can than always ask some end user on
weird system AxyDfs-3.45a to run the same code with $dbh->{DBDverbose} or
$sth->{pg_sth_debug} to some useful value.
> > So if you are going to support this driver from 5.6.1 and up with no
> > need to
> > go back, just leave these out.
> >
> > FWIW 5.8.0 could still be build with 5005 threads, though it was marked
> > depricated and unsupported. In 5.9.0 (the development track), *all*
> > 5005
> > thread support has been removed.
>
> If I leave it out, will *un*threaded perls prior to 5.6.1 work without
> dTHR? If so, then I just might leave it out, since no one in her right
> mind uses threads before 5.8.0 for production code. Probably not even
> 5.8.0, come to think of it.
>
> > I don't know if you are writing the XS in HLI or in E/SQL, but most
> > HLI or
> > E/SQL have describe functions. My DBD::Unify is completely written in
> > E/SQL,
> > so take a peek in there to see how describe works. E/SQL is most often
> > slower
> > than HLI, but much more portable. DBD::Unify is not to be taken as an
> > example
> > driver, because it (still) lacks a lot of funtionality. If you want to
> > `steal'
> > code, use DBD::Oracle and DBD::ODBC, that's how I started DBD::Unify :)
> > [ Thanks Tim, Jeff, and other authors ]. Good aditional `example'
> > drivers to
> > steal from are also FreeTDS and Ingres.
>
> Um, "E/SQL" and "HLI"? I'll have to Google for those when I'm off this
HLI High Language Interface. Usually a set of functions grouped in a set of
libraries that enables you to write your own C/Pascal/Fortran/... code
to use the database
E/SQL Embedded SQL. The .xs does not have direct calls to the HLI, but needs
a preprocessor specific to the target database to translate the SQL
statements to HLI before the real C compiler can deal with it.
Since E/SQL is translated to HLI by a preprocessor, it will close to never be
as efficient as when you'd written the HLI yourself, but it is much more
readable, and for sure a lot more portable.
> plane, had a good night's sleep, and back online. I'll definitely check
> out DBD::Unify, though; thanks!
>
> > Because some database interfaces need to pass storage space along with
> > the
> > retreival statement, so you need to know how many input and output
> > variables
> > are expected before you pass it.
>
> Well, for PostgreSQL, it's because DBD::Pg has been doing the parsing
> for placeholders and replacing them with the proper values.
>
> >> Same issue as comments. Consider this statement:
> >>
> >> SELECT * FROM table WHERE a = ? AND b = '?' /* is this right? */
> >
> > An unquoted question mark is a placeholder. The driver should take
> > care of the
> > neccasary conversions. So if a is a numeric, the driver should take
> > care that
> > "1" is correctly converted to the required format.
>
> DBD::Pg can only do this if bind_param() passes in the proper data type
> constants.
>
> Thanks for your comments!
Welcome to this neverending world of tuit shortage :/
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
