WebSimpleDB object caching

[Kris Zyp-4]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Is there any intended restrictions on caching of objects returned by
queries and gets with WebSimpleDB? 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();

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? Also should store.get(l1.id)
== l1 be false as well? In other words, if one does l2.number =
'3322', is there any guarantee that l1.number would be unchanged (or
would be changed)?
Thanks,

- --
Kris Zyp
SitePen
[phone]
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkr2RTgACgkQ9VpNnHc4zAwU4wCeIELYoOJX+WuUwpPhmp9Z4XHP
GWUAnjsju7ZfFQssRkrKAPyg5TJhMhNt
=Dws5
-----END PGP SIGNATURE-----

[Nikunj R. Mehta]

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

[Kris Zyp-4]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 


Nikunj R. Mehta wrote:

> 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.

I don't have a hard requirement, we are just using the WebSimpleDB API
as a common interface to different storage system in server side
JavaScript. But, if store.entities().next() !==
store.entities().next() is not guaranteed, it could potentially add an
extra burden on users. If they modify an object return from a cursor,
and have not yet called update or put with it, then it would be
unknown if a future cursor might return the modified object or a fresh
object without the modification. Guaranteeing store.entities().next()
!== store.entities().next() seems like it would provide more
determinism. Alternately, we could guarantee store.entities().next()
=== store.entities().next(), but I don't think you are wanting that,
and it would put extra burden on spec implementors to keep track of
objects that have been returned from cursors.

Presumably the identity guarantee of objects returned from cursors
should be the same as for get(id) calls (if cursors always return a
new JS object, so should get(id)).

Thanks,

- --
Kris Zyp
SitePen
[phone]
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkr5y+4ACgkQ9VpNnHc4zAweBwCfYEVIuyOwR6epf8Ty4IeV9AT0
NrEAoJgaIz6n9SE8qTor82ZtapaugdGh
=kJxr
-----END PGP SIGNATURE-----

[Nikunj R. Mehta]

On Nov 10, 2009, at 12:24 PM, Kris Zyp wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Nikunj R. Mehta wrote:
>> 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.
> I don't have a hard requirement, we are just using the WebSimpleDB API
> as a common interface to different storage system in server side
> JavaScript. But, if store.entities().next() !==
> store.entities().next() is not guaranteed, it could potentially add an
> extra burden on users. If they modify an object return from a cursor,
> and have not yet called update or put with it, then it would be
> unknown if a future cursor might return the modified object or a fresh
> object without the modification. Guaranteeing store.entities().next()
> !== store.entities().next() seems like it would provide more
> determinism. Alternately, we could guarantee store.entities().next()
> === store.entities().next(), but I don't think you are wanting that,
> and it would put extra burden on spec implementors to keep track of
> objects that have been returned from cursors.

(Sorry for the delay in responding on this matter. I was on vacation  
last week after a hectic period doing non-WG related work.)

When dealing with low-level data storage APIs, programmers have  
historically wanted multiple options for memory management to choose  
from. These options vary from letting the application perform memory  
management (so it can reuse objects if it wants to) to letting the  
library allocate space each time. Berkeley DB, the API I am most  
familiar with, offers library malloc'ed, library realloc'ed, and user  
allocated memory.

The questions and choices for us are:

1. How does a program to specify their choice of memory management?
   * On a per-call basis
   * No such choice
2. What do we make the default behavior for memory management?
   * User agent allocated
   * Program allocated

I am in favor of there being no choice in this API (to make a decision  
on the first question). Consequently, I am in favor of the user agent  
allocating memory (to make a decision on the second question).

The net result will be that store.get(id) !== store.get(id).

>
> Presumably the identity guarantee of objects returned from cursors
> should be the same as for get(id) calls (if cursors always return a
> new JS object, so should get(id)).
>

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