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
> 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 :)