> From: Ard Biesheuvel [mailto:[EMAIL PROTECTED] > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
