W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

RE: [Bug 11270] New: Interaction between in-line keys and key generators

From: Pablo Castro <Pablo.Castro@microsoft.com>
Date: Wed, 10 Nov 2010 22:02:23 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <F753B2C401114141B426DB383C8885E0622BC883@TK5EX14MBXC124.redmond.corp.microsoft.com>

From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
Sent: Wednesday, November 10, 2010 1:50 PM

>> On Wed, Nov 10, 2010 at 1:43 PM, Pablo Castro
>> <Pablo.Castro@microsoft.com> wrote:
>> >
>> > From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of bugzilla@jessica.w3.org
>> > Sent: Monday, November 08, 2010 5:07 PM
>> >
>> >>> So what happens if trying save in an object store which has the following
>> >>> keypath, the following value. (The generated key is 4):
>> >>>
>> >>> "foo.bar"
>> >>> { foo: {} }
>> >>>
>> >>> Here the resulting object is clearly { foo: { bar: 4 } }
>> >>>
>> >>> But what about
>> >>>
>> >>> "foo.bar"
>> >>> { foo: { bar: 10 } }
>> >>>
>> >>> Does this use the value 10 rather than generate a new key, does it throw an
>> >>> exception or does it store the value { foo: { bar: 4 } }?
>> >
>> > I suspect that all options are somewhat arbitrary here. I'll just propose that we error out to ensure that nobody has the wrong expectations about the implementation preserving the initial value. I would be open to other options except silently overwriting the initial value with a generated one, as that's likely to confuse folks.
>>
>> It's relatively common for me to need to supply a manual value for an
>> id field that's automatically generated when working with databases,
>> and I don't see any particular reason that my situation would change
>> if using IndexedDB.  So I think that a manually-supplied key should be
>> kept.

That would be okay with me. One bit of fine-print on this one is that if you're calling store.add() with an explicit key then you may get a unique constraint error (which would never happen with a generator if you never provided your own keys). Also, did we settle for having put() never adding a new record if one didn't exist? If put() can create a record, then things still work but become a bit more elaborate in that put() would create a new record either if the key is not present in the object or if it's present but the value doesn't exist in the database, while it would update a record if the value was present and it existed as a key in the store.

-pablo

Received on Wednesday, 10 November 2010 22:03:00 GMT

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