Re: Resending Re: WebDatabase review: SQLResultSetRowList

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. UAs should limit the size of ResultSets to something reasonable.
Perhaps there should also be an error code if the UA cannot return all the
rows. Or perhaps it is just up to the developer to select count(*) to see if
he got all of them.

> *
>
>    - Property names on result sets are based on column names used in the
>    query or defined in the view/table. These name sources (colmns, selections)
>    are case insensitive but the row object would have to use case-sensitive
>    names. Is there a way that objects can be accessed without case
>    insensitivity?
>
> *
>
> Can you point out a situation where this mismatch would be an issue? It
seems like developers could simply use the correct case when referring to
the columns from JS.

- a