On 16-Oct-08, at 10:54 AM, Markus Hoenicka wrote: > Quoting Toby Thain <[EMAIL PROTECTED]>: > >> The Ingres driver also works this way. It's a while since I wrote >> that code, but a comment in the code says that this is due to the >> mismatch of Ingres API and libdbi API. libdbi offers 'random access' >> to rows of a resultset, but Ingres is only able to provide the >> complete resultset through its C API. libdbi is forced to buffer the >> whole thing. >> >> I don't know how the other drivers do it. >> > > I guess I'll have to cite historical reasons once again. Both the > MySQL and PostgreSQL client libraries provide a result handle after a > successful query (available through calls to mysql_store_result() and > PQexec(), respectively). You can the use built-in functions to > randomly access these result sets. Apparently the client library has > to do the buffering then. > > The sqlite/sqlite3 drivers use a convenience function provided by the > sqlite client library which creates a result table similar to the one > you have to create for ingres and oracle. If I used the new > prepare/exec/finalize interface recommended these days for sqlite3, > I'd have to loop over the rows until done, with no chance to implement > random access. So from my point of view it boils down to either being > efficient without random access or being convenient with performance > bottlenecks. I'm afraid we can't satisfy both needs at a time, but > should we implement two interfaces and let the users choose based on > their project's needs? Is looping over rows the lowest common > denominator that all database engines provide, and be it through a set > of driver functions?
I'm confused about your response. If I understand Vincent, he complains that libdbi always buffers the whole resultset in memory. It does this because this is *already* the "lowest common denominator" approach to offering random access to rows. My Ingres data point was one more example of a driver that delivers the entire resultset so that libdbi's random access can work (as you explain about SQLite3). The only way to "stream" the resultset to an application would be to use a database specific client API directly; libdbi as it stands can't do it. Are you proposing a new libdbi "mode" that would disable random access and enable row-at-a-time access? --Toby > > regards, > Markus > > -- > Markus Hoenicka > [EMAIL PROTECTED] > (Spam-protected email: replace the quadrupeds with "mhoenicka") > http://www.mhoenicka.de > > > ---------------------------------------------------------------------- > --- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Libdbi-drivers-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libdbi-drivers-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
