Professional Web Applications Themes

[PHP-DEV] differences in the RDBMS ext API's - PHP Development

> From: Ard Biesheuvel [mailto:abiesphp.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 ...

  1. #1

    Default RE: [PHP-DEV] Re: differences in the RDBMS ext API's

    > From: Ard Biesheuvel [mailto:abiesphp.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
    _query and dont buffer with _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: [url]http://www.php.net/unsub.php[/url]

    Lukas Smith Guest

  2. #2

    Default Re: [PHP-DEV] differences in the RDBMS ext API's

    Hi Lukas,

    good job!
    > - bind
    ...
    > mysqli_bind_param
    and mysqli_bind_result
    > - errno/error
    mysqli supports 2 types of errno/error
    mysqli_errno/error and mysqli_sqlstate. mysqli_sqlstate returns ANSI/ODBC
    conform errorcodes.
    > - next_result
    > only exists in fbsql and mssql
    on todo for mysqli until MySQL AB added an separate call for multi queries.
    > - pconnect
    > missing because it was found to be not feasible in mysqli
    will be replaced by an call to an external broker

    missing: fetch
    to retrieve data from a prepared statement (mysqli_fetch)

    Georg

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: [url]http://www.php.net/unsub.php[/url]

    Georg Richter Guest

Similar Threads

  1. [PHP-DEV] differences in the RDBMS ext API's
    By Lukas Smith in forum PHP Development
    Replies: 3
    Last Post: September 14th, 02:29 AM
  2. RDBMS
    By lak25 in forum Macromedia Flash Data Integration
    Replies: 0
    Last Post: August 26th, 09:45 PM
  3. [PHP-DEV] differences in the RDBMS ext API's
    By Marc Boeren in forum PHP Development
    Replies: 1
    Last Post: September 25th, 02:46 PM
  4. [Fwd: [PHP-DEV] differences in the RDBMS ext API's]
    By Manfred Stienstra in forum PHP Development
    Replies: 0
    Last Post: September 25th, 10:37 AM
  5. [PHP-DEV] differences in the RDBMS ext API's
    By Ard Biesheuvel in forum PHP Development
    Replies: 0
    Last Post: September 25th, 09:38 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139