Extra (now passing) oracle test which led to the work in 37b5ab51
authorPeter Rabbitson <ribasushi@cpan.org>
Sat, 7 Dec 2013 15:07:57 +0000 (16:07 +0100)
committerPeter Rabbitson <ribasushi@cpan.org>
Fri, 13 Dec 2013 17:54:36 +0000 (18:54 +0100)
commitd07f715dddc9e64362a168cf05896e89002a1aca
treefbfd388029bc6dada9318ab0130603a3016d0293
parentfa7907b0476a2aa2fc866ba6326cb49b379b027e
Extra (now passing) oracle test which led to the work in 37b5ab51

Grumble - this was such a simple thing to diagnose and it took a month to
see it. The culprit was the (correctly bisected to) cleanup in d87929a4,
which failed to take into account that an empty connect() can still lead
to a healthy $dbh, given system-based authoriozation, and no attributes
being passed in.

For the curious - the difficulty to diagnose was further exacerbated by
the apparent insanity of what was being generated - a (known, existing)
method name was somehow leaking into the generated SQL. In reality when
we failed to determine the driver, we also failed to determine the SQLA
subclass, which in turn made us call a nonexisting method on $sql_maker,
but *surprise* - SQL::Abstract (the granddady of it all) defines an
AUTOLOAD. Khaaaaaaaaaaaaa....
lib/DBIx/Class/Storage/DBI/Oracle/Generic.pm
t/73oracle.t