Long long ago, on Sun, Sep 15, 2002 at 12:41:18PM -0700, David Wheeler wrote:
>
>
> * Line 32, I've added the comment "# Broken? Changed?". This is because
> the behavior of the Kids attribute is somewhat unpredictable. I've
> written a separate test for this issue (attached as 07kids.t). When I
> run it on Darwin, Perl 5.8.0, DBI 1.30, all tests pass. When I run it
> on i686-Linux, Perl 5.6.1, DBI 1.30, however, they don't. This is
> because, on the linux/Perl 5.6.1 setup, the value of the "Kids"
> attribute attached to the database handle is different in a HandleError
> code reference than it is later. I have no idea why, or why it's not
> consistent between configurations. Try running 07kids.t on different
> platforms to see how it works.
I'll look into this.
> * Line 66, I expected this test, which I've marked with the comment "#
> Shouldn't this be 1? It returns ''", to return 1. I've set RaiseError
> => 1 when I connected, so I expected it to be the same in the driver
> handle as it is in the database handle. Is this a valid assumption?
No. Attribute changes only affect the handle they were applied to
and any children created later from that handle. They don't affect
the parent handle.
> * Line 97, The CachedKids attribute doesn't seem to be implemented for
> statement handles, event though it is documented in 'ATTRIBUTES COMMON
> TO ALL HANDLES'. 'Course, that documentation doesn't mention $sth, so
> maybe it should be moved to just the $dbh section?
Statement handles don't have kids, but the DBI ought to recognize
the attribute name. Fixed.
> (And should there be a section for $drh objects, BTW?).
Using a $drh directly is discouraged (partly because it's likely
to break if you use the proxy).
> * Lines 135-141. The PRECISION and SCALE attributes return undef here,
> rather than array references. It seems to me that either they should
> return empty array references or should be documented to return undef
> when the DBD hasn't implemented them (which I assume is the case with
> ExampleP).
Yeap. It's kind of a general presumption that a valid but unsupported
attribute returns undef. I'd be happy to clarify any general docs
but I'd rather not repeat that statement for each attribute.
> * Line 148, No default seems to be implemented for the CursorName
> attribute. Michael Chase offered a patch to address this issue:
Fixed, thanks.
> The same may also be true for the Statement attribute, since Frederic
> Van de Velde reports to me that he gets a
> "DBI::db=HASH(0x819a0d8)->{Statement}: unrecognised attribute" error
> with DBD::mysql v2.1018 and DBI 1.30.
Ah, if he hadn't prepared any statements then I see the bug. Fixed.
> Should *all* of the attributes
> defined in the documentation have defaults?
In as much as they should be recognized (so no error) and probably return undef.
> * Running these test under PurePerl DBI fails hard. The principal issue
> seems to be that where DBI returns a null string C<''> as the false
> value for many attributes, PurePerl returns C<undef>, instead. If it
> means to follow the general Perl pattern, it should probably return
> null strings like DBI does.
I've changed the tests to just do ok(foo) or ok(!foo).
But I've also cleaned up a few related PurePerl internals.
> * Also under PurePerl, attempts to access the "Profile" attribute (on
> lines 47 and 110) causes the script to simply exit. Or at least that's
> what it looks like -- the tests simply stop.
Fatal errors were not getting caught and reported due to the zz_*_pp.t
wrapper code. Fixed.
> * There are a couple of other inconsistencies between the DBI and
> PurePerl DBI in terms of attributes, too -- run the tests to see.
I think I've got them all nailed now, including those spotted by new
tests (there's 125 attribue tests now :)
Many thanks for doing this David.
Tim.
