On Fri, Aug 27, 2004 at 05:23:55AM -0400, T. Onoma wrote:
> > I think it would be reasonable also for DBI to abstract some common
> > operations: e.g.
>
> My first inclination (and I expect everyone elses too), after reading over
> your excellent suggestions, was for DBI to gain some new high-level methods.
> But then it dawns on me, your examples almost suggest that DBI define its own
> superset of SQL -- now that's interesting. Perhaps even worth a fork, or a
> subproject that sits, AOP style, on top of "core" DBI.
That's one possible approach. However, I think you'd probably end up with a
bunch of different object (sub)classes - one handling Mysql instances, one
handing Sqlite instances, etc. By the time you've done that, it might turn
out to be simpler just to use the native underlying APIs rather than doing
via DBDs. I'm not saying that's definitely the case, but certainly I came
very close to this when I was writing an application which tried hard to be
database-neutral; I was having to create separate object classes for each
database type, and the amount of underlying DBI layer I was using was little
more than do/execute/fetch.
Regards,
Brian.
|
