W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: Resending Re: WebDatabase review: SQLResultSetRowList

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 21 Sep 2009 11:50:16 -0700
Message-ID: <63df84f0909211150j2f0aa600n122c8fc3002490d9@mail.gmail.com>
To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
Cc: Aaron Boodman <aa@google.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Mon, Sep 21, 2009 at 11:09 AM, Nikunj R. Mehta
<nikunj.mehta@oracle.com> wrote:
>
> On Sep 21, 2009, at 10:47 AM, Aaron Boodman wrote:
>
> On Mon, Sep 21, 2009 at 10:33 AM, Nikunj R. Mehta <nikunj.mehta@oracle.com>
> 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.

[1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html

/ Jonas
Received on Monday, 21 September 2009 18:51:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT