Re: A valuable addition to PHP...

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.

I have written something that does this in two directions: listing out the
indices, tables, columns, etc. For a simpleminded db abstraction layer for
work. I can provide code shortly.

IMHO the database "abstraction toolkits" are all missing the point. In my
scripts, I want my variables. Now. It failed? Not the concern of the
script.

So far I've laid out 5 functions:

# returns the value of that column or NULL if it's NULL
$scalar = db_value("SELECT column FROM table WHERE unique_id=5"):

# returns an array of values of these columns
$list = db_list("SELECT column FROM table");

# returns a hash[column] = value
$row = db_row("SELECT * FROM table WHERE unique_id=5");

# returns a array of hashes
$rows = db_row("SELECT * FROM table");

# for sending updates, etc.
$result = db_send("UPDATE/INSERT/DELETE whatever");

All the guts of connections, interation, freeing results, etc. are hidden.
I've even implemented failover behind the scenes.

Error handling is ambiguous with respect to NULL values, so that gets a -1
until something exception-like appears in the language. (And I'm not in a
hurry for that.)

This has turned out to be really effective.

One thing which would also be amazing (also borrowed from some simple-DBI
thing) is to automatically map primary keys into hashes. So when fetching a
bunch of rows that have a primary key:

$rows = db_row("SELECT pkey, value FORM table", 'user_id');
# $rows['somepkey'] is then a reference to the value of that key

Get it?