Tim Bunce wrote: > I'm interested to hear stories of people who have subclassed the DBI, > or used modules that subclass the DBI. >
My subclasses (or attempted subclasses): DBIx::Chart - worked (tho it took me a few years to get it right ;^) DBIx::Threaded - didn't work (tho I managed to deliver a "faux" subclass) > Was subclassing the DBI a good approach? DBIx::Chart - yes, tho it might have been a bit easier DBIx::Threaded - no, tho it could have been useful but for the magic handle requirement (see below) > > Where there any problems? DBix::Chart - since it was both subclassing, *and* encapsulating/ aggregating DBI objects, things got a bit confusing as to which DBI object's methods/members to expose for any given call. Not certain DBI can do anything about that, tho. DBIx::Threaded - the requirement that handles *must* go thru DBI at some point to acquire "magic" created an insurrmountable issue (since the handles returned by DBIx::Threaded's needed to be threadsafe and implement Thread::Queue::Queueable). Its not clear to me precisely why DBI requires the magic, other than as "belt and suspenders" security ? (Or maybe to support the tied object mechanism ?) And as I suggested a while ago, if an i/f were provided to "conjure" a handle so it acquired the needed magic, that might have solved the issue. Also, being able to capture the driver-specific methods installed via install_method would be nice to support same in subclasses such as DBIx::Threaded. > > Could it have been done well/better some other way? See comments above wrt magic and installed methods. > > Thanks! > > Tim. > Regards, Dean Arnold Presicient Corp.
