On Sep 21, 2009, at 11:50 AM, Jonas Sicking wrote:
On Mon, Sep 21, 2009 at 11:09 AM, Nikunj R. Mehta
<[email protected]> wrote:
On Sep 21, 2009, at 10:47 AM, Aaron Boodman wrote:
On Mon, Sep 21, 2009 at 10:33 AM, Nikunj R. Mehta <[email protected]
>
wrote:
I haven't seen any responses to the issues below. I hope the
editors can
respond to these and several other of my messages about the
WebDatabase
draft.
I'm not an editor, but I'll take a swing at answering some of these
based on
my mental model for this feature.
On Aug 31, 2009, at 3:56 PM, Nikunj R. Mehta wrote:
SQLResultSetRowList
The item() method may take a long time to process. Shouldn't this
have an
asynchronous version with a callback?
The ability to randomly access rows in the row set increases the
likelihood that the item operation will take an arbitrarily long
time. Plus,
supporting random access is very expensive on limited memory
devices.
Offer next() and previous() methods that returns the next and
previous row
respectively.
Offer absolute() and relative() call that may fail. See
java.sql.ResultSet.absolute() and java.sql.ResultSet.relative().
The length attribute could require accessing all the rows, which
would use
too much memory on limited memory devices.
Specify that the SQLResultSetRowList that resulted from a call to
SQLTransaction.executeSql() can only be accessed during the
execution of the
associated SQLStatementCallback
I don't think ResultSet should ever go to disk, it should be memory-
backed
only.
I don't see that as being a reasonable requirement. What happens when
databases store blob data and multiple rows with blobs of large
sizes are in
the result set? It is hard to justify this requirement because it
gives
advantage to certain implementations over others?
If the spec can be made to return FileData objects, as defined by [1],
then the actual blob data does not need to be stored in memory, just
FileData objects with some sort of internal pointer to where the
actual data is stored. This is the solution localStorage is defined to
use.
Could we actually relate the FileData with SQL without defining a
means of writing to the database? Or would we have an asymmetric
interface where writing is done as String and reading as FileData?
LocalStorage depends on structured clone, whereas SQL doesn't deal
with structured clone at all. So I am not sure if the analogy flows.
But certainly, the idea is worth considering.
[1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
/ Jonas
Nikunj
http://o-micron.blogspot.com
