Re: Resending Re: WebDatabase review: SQLResultSetRowList

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?

> 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

Nikunj
http://o-micron.blogspot.com