First off, I have to say that I'd never heard of PEAR before, but it looks
like a good database abstraction layer.
On Thu, Mar 29, 2001 at 10:17:44PM -0500, Stephen van Egmond wrote:
> On Thu, Mar 29, 2001 at 05:16:54PM -0500, Andrew Hammond wrote:
> > independant way of accessing metadata. Writing SQL queries that derive
> > metadata by futzing around with the pg_* tables works but is totally
> > non-portable. What I would really like to see is a database interface
> > layer that encapsulates all that nasty mess. Metadata and other
> > introspective stuff is a glaring ommission from SQL.
> IMHO the database "abstraction toolkits" are all missing the point.
You have definately missed my point. The key thing I'm interested in is
META data and introspective abilities. For example, I'm NOT talking about
selecting some data out of a table. I AM talking about getting a list of
databases in the dbm, tables/objects in the database, columns in the table.
That kind of thing. This is interesting because meta-data is exactly what
you need if you want to write meta-programming. Like, say, a generic web /
database interface...
> In my scripts, I want my variables. Now. It failed? Not the concern
> of the script.
How do you intend to deal with runtime error situations? Debugging?
Also, why didn't you use an object oriented approach so you could have
multiple connections to multiple databases?
Aside from those two rather serious issues, your api looks pretty good.
Personally, I'd rename the get_rows function to something like get_table.
get_rows is too close to get_row. I'd be apt to miss the s by accident
and spend a few hours doing blank stare debugging.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster