Re: WebSimpleDB object caching

Hi Kris,

Thanks for the insightful feedback.

On Nov 7, 2009, at 8:12 PM, Kris Zyp wrote:

> Is there any intended restrictions on caching of objects returned by
> queries and gets with WebSimpleDB?

Currently, the spec does specify any required behavior in terms of  
caching objects. As an implementation choice, it would be good if the  
object returned by a database from a cursor can be reused by the user  
agent.

> For example (using the address book
> example in the spec):
>
> |database = window.openDatabase('AddressBook', '1', 'Address Book',  
> true);
> database.transaction(function(Transaction txn) {
> var store = txn.getEntityStore('Contact');
> var allCursor = store.entities();
> var lCursor = store.getIndex('ContactName').entities('L');
> var l1 = lCursor.next();
> l1 = lCursor.next();
> var l2 = allCursor.next();

 From this example, the two calls to lCursor.next() may return the  
exact same object each time even though its contents may be completely  
different. In other words, they could respond positively to the  
identity match '===' but not to the equality match '=='. As a spec  
user which one do you prefer? As spec implementors, what would you  
prefer?

>
> Now, is there any intended requirement that l1==l2 must be false even
> if ||they represent the same record (that is l1["id"] === l2["id"]) or
> can cursors potentially reuse JS objects?

Cursors can potentially reuse JS objects. Would you object if this  
were to be a requirement of the spec?

> Also should store.get(l1.id)
> == l1 be false as well?

In general, nothing can be said about '==' test, except on primitives  
that are supported by the spec. I currently intend to support only  
String and Number types for use as keys in the spec. That means,

store.get(l1.id).id == l1.id but _not_ store.get(l1.id) == l1

> In other words, if one does l2.number =
> '3322', is there any guarantee that l1.number would be unchanged (or
> would be changed)?

There is no such guarantee presently. Please explain your requirement  
as that might help shed light on which route to take.

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

Received on Tuesday, 10 November 2009 00:37:11 UTC