Tim Bunce wrote:
Probably no good reason, or at least none that I can remember. Patches welcome! Send me your auth.perl.org username and I'll give you commit rights...
I don't have a patch, but here's what appears to be going on: DBI::_new_sth() calls DBI::_new_handle(), which creates both the inner tied hash with the supplied attributes hash, then creates the outer blessed version of said hash. Then it calls _setup_handle() to finish things up. _setup_handle() ends up in dbih_setup_handle(), which populates the hash with attributes inherited from the parent object, and then *explicitly sets NUM_OF_FIELDS to -1* without ever verifying if NUM_OF_FIELDS is already defined. Furthermore, none of the attributes to _new_sth/_new_handle ever get processed by dbih_set_attr_k() (ie, DBI's STORE()), so any attribute processing performed there is not applied to constructor-provided attributes. So it appears that _new_sth()/_new_dbh() constructor attributes only support driver-specific attributes and/or inocuous DBI-level attributes (prior to my recent efforts, I've only ever set Statement and CursorName), and the driver must apply any other DBI-level attributes *after* the handle is created...which is a minor PITA. Might dbih_setup_handle() be able to call dbih_set_attr_k() with each supplied attribute to provide that processing ? Or am I overlooking something ? OTOH, this horse is out of the barn and 2 miles down the road, so just doc'ing the situation may be best for now. - Dean
