On Monday 27 February 2006 11:15, Chris Johnson wrote:
A real abstraction would allow you to encapsulate the database objects as objects, and the code reading and writing the attributes of those objects would never need to use SQL. I'm not sure if we want to go that far, or not. (Incidentally, I'm writing such a "real" object abstraction for MySQL and PostgreSQL for my employer right now.)
Are there any other db abstraction libraries out there we should look at? I certainly would be interested in taking a look at them myself.
Having written a Drupal-esque db abstraction layer at work, I found that abstracting insert, update, and delete statements is quite easy. They're all very regular, and in fact the abstracted form I had takes associative arrays which makes them far easier to work with, even without database abstraction. (I'm not sure if something similar would be of interest to Drupal, but I'd be happy to code it up once HEAD opens again.) Select statements are the tricky one, since they can get very complicated. I've not figured out how to properly abstract those. That's where the major DB libraries get so big, and where stuff like PEAR::DB::DataObjects becomes attractive. Has anyone found a good abstraction model for select statements that they like? -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson