The following message is a courtesy copy of an article
that has been posted to gmane.comp.db.sqlite.jdbc as well.
"David Crawshaw" <[EMAIL PROTECTED]> writes:
> Cursors are a strange, unnecessary invention with very complex
> performance/memory use implications depending on the nature of the
> SQL query.
I think this gets down to some of the fundamental differences between
Sqlite and all other JDBC-accessible databases, and I think it's good
that a better understanding of this difference is beginning to emerge.
- Client/server databases assume that moving data from the server to
the client is relatively expensive, so they provide APIs (cursors,
various levels of transactional isolation, etc) that let the
client manage state inside the server.
- Sqlite assumes that the client and the server are on the same
machine, so simply mass-copying the data from the server to the
client is a better choice than making the server more complex.
> http://www.sqlite.org/cvstrac/wiki?p=ScrollingCursor
... which says: "Rule Number 1: Do not leave queries open waiting for
the user input."
I'm starting to wonder if it would make sense for SqliteJDBC to
*always* retrieve 100% of the data represented by a ResultSet at the
time the executeQuery() is performed, cache that data in the ResultSet
object, close the ResultSet, and then spoon-feed bits of that big
chunk of data back to the JDBC client as requested via the ResultSet
API.
I believe that this would give "perfect JDBC semantics" at the expense
of increased memory consumption on queries that return very large
amounts of data.
- a
--~--~---------~--~----~------------~-------~--~----~
Mailing List: http://groups.google.com/group/sqlitejdbc?hl=en
To unsubscribe, send email to [EMAIL PROTECTED]
-~----------~----~----~----~------~----~------~--~---
