On Tue, Aug 16, 2005 at 12:12:02PM -0700, Dean Arnold wrote: > Tim Bunce wrote: > > >And nobody mentioned JDBC as a potential model. Odd that. > > I was sorely tempted to do so (and did mention it a few times in > my posts, along w/ ODBC and ADO.NET), but there are some things about > JDBC which rub me the wrong way (e.g., explicit set/get methods for every > data type no true binding support; the lame "bulk" interface; etc.). > I'm not crazy about all the DataSource business, either.
I think all those are fixable for Perl/Parrot. Same for the painful need for try & catch every few lines. > But the threading support, the Factory pattern presented by Statement > classes, the nice separation of metadata from > statements/resultsets/connections, and XA would certainly be nice > models to follow. That's what I'm thinking. Not only nice but also well proven and widely understood. > One area of concern I have is the ability to subclass. I've been > struggling w/ trying to subclass+extend JDBC the same way I subclass > DBI for some things, and haven't found any app-neutral solutions just > yet (trying to wrap another JDBC driver and expose its driver specific > methods seems to require a lot of extra heavy lifting). There are lots of people who have problems or complaints about subclassing the DBI :) Tim.
