> From: Ard Biesheuvel [mailto:abies@php.net]
> Sent: Thursday, September 25, 2003 11:36 AM
>
> > Please correct me where I am wrong. Some query() functions might be
> > actually be unbuffered_query() etc. And while doing such a boring
work
> > you tend to make mistakes. Finally I don't know all API's by heart
nor
> > have I used all of them.
>
> First of all, in my opinion it would be more useful to concentrate on
a
> true cross-database PHP-level data-object API which can really hide
the
> differences between db implementations, instead of using the exact
same
> function names, and ignoring the implementation differences between
the
> various systems. I'd rather implement buffered queries at the
PHP-level
> for all extensions instead of for Interbase only.
Tell me about it :-)
I am the author of PEAR::MDB.
And right this second I am fixing bugs in the row buffering of the
oracle and interbase drivers :-)
Rest assured that I see this only as a complementary effort to ease the
life of users that write database driven applications with PHP.
> > - bind
>
> mssql_bind()/mysqli_bind_result() are used to bind output parameters
to
> variable references, which is totally different from binding variables
> values at query execute time. The former is not supported directly by
> the Interbase API, but could by implemented in the PHP layer.
Yeah I guess in a lot of cases it is a question of we want to emulate
certain features in the extension or not. This goes in the direction of
an ext that creates a common API.
> > - data_seek
> > - result
> > - query
> > - unbuffered_query
>
> Query result buffering in Interbase is carried out by the client
> library. The only tunable is the buffer count in ibase_connect(). It
> would be possible to have ibase_query() fetch an entire result and
store
> it internally before returning. This would enable the use of
> data_seek(), which is currently unsupported, but it would also break
BC,
> as current applications that work with huge result sets would start
> consuming an awful amount of memory.
>
> Maybe call it buffered_query() and let individual extensions decide
> which version query() maps to ?
Yeah quite tricky, seeing that alot of ext currently buffer with
xxx_query and dont buffer with xxx_unbuffered.
Maybe cleaning this stuff up will have to wait until PHP5?
> > - errno
> > ifx_error
> > odbc_error
> > ora_errorcode
> > missing in ibase, ingress, mssql, msql, oci, pg, sqlite, sybase
>
> Has been implemented and committed to HEAD as ibase_errcode() :-)
> (So now is the time for a name change)
I guess errorcode is more clear
> > - escape_string
> > missing in fbsql, ifx, ibase, ingress, mssql, msql, odbc, oci,
ora,
> > sybase
>
> ... and for a reason!
>
> If you use params + binding, the medieval practice of escaping strings
> is unnecessary. Will probably never be implemented for Interbase.
Well not everybody is ready to make that jump.
> > - fetch_array
> > - fetch_row
> > missing in ibase, oci, ora, sqlite
>
> Fetch_row /is/ supported by Interbase.
> Is there a distinction in semantics between fetch_row() and
> fetch_array() ? Don't all the fetch_() functions fetch a row ?
>
> Maybe fetch_row() with a modifier should be an alias for the other
fetch
> functions (like in mysql) This would also allow changing the
interfaces
> without breaking BC.
To be honest all those fetch methods do seem kind of reundant. Actually
the only one really needed is fetch_array and fetch_object. fetch_assoc
and fetch_row are essentially the same as fetch_array with the fetchmode
hardcoded.
> > - insert_id
>
> Cannot be supported by Interbase, because it uses generators and
trigger
> for auto-inc fields. There's a function ibase_gen_id() in HEAD, which
> can be used to generate an id and insert it manually into the id
> position. This provides basically the same functionality.
Autoincrement cannot really be emulated.
But I was not targeting that with my mail.
Emulation should be handled else where.
> > - next_result
> > only exists in fbsql and mssql
>
> Only makes sense if you allow chained queries. This is not the case in
> Interbase.
Again emulation is beyond the scope of the default extensions.
> > - num_rows
>
> Has been implemented and removed again from HEAD, as the underlying
API
> function returns inconsistent results. Could be re-implemented to work
> with buffered queries.
Yup. It only really makes sense in combination with buffered queries.
> > - select_db
>
> Has no meaning in Interbase, because you cannot connect to a server
> without specifying the database.
Yup, as is the case with a lot of other rdbms.
Regards,
Lukas
