W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [IndexedDB] Changing the default overwrite behavior of Put

From: Nikunj Mehta <nikunj@o-micron.com>
Date: Thu, 17 Jun 2010 12:40:54 -0700
Cc: Shawn Wilsher <sdwilsh@mozilla.com>, Kris Zyp <kris@sitepen.com>, Jeremy Orlow <jorlow@chromium.org>, public-webapps WG <public-webapps@w3.org>
Message-Id: <3DC4A95E-B84C-4EDA-AF3D-C6CFF972B448@o-micron.com>
To: Jonas Sicking <jonas@sicking.cc>
Would be useful to bear in mind the semantics of the two methods:

1. If storing a record in an index that allows multiple values for a single key,
  a. add is going to store an extra record for an existing key, if it exists.
  b. put is also going to store a new record for the existing key, if it exists.
  c. add is going to store the first record for a key, if it doesn't exist.
  d. put is also going to store the first record for the key, if it doesn't exist.
2. If storing a record in an object store or an index that allows a single value per key,
  a. add is going to store the record for a key, if it doesn't exist.
  b. put is going to update the existing record for the key, or create a new record if one doesn't exist for the key.

Only cursor operations can be used to update the value of a record once stored in a multi-value index.

Nikunj
On Jun 17, 2010, at 10:40 AM, Jonas Sicking wrote:

> On Thu, Jun 17, 2010 at 10:33 AM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:
>> On 6/17/2010 10:26 AM, Kris Zyp wrote:
>>> 
>>> My order of preference:
>>> 1. parameter-based:
>>> put(record, {id: "some-id", overwrite: false, ... other parameters ..});
>>> This leaves room for future parameters without a long positional
>>> optional parameter list, which becomes terribly confusing and
>>> difficult to read. In Dojo we generally try to avoid more than 2 or 3
>>> positional parameters at most before going to named parameters, we
>>> also avoid negatives as much as possible as they generally introduce
>>> confusion (like noOverwrite).
>>> 2. Two methods called "put" and "create" (i.e. put(record, id) or
>>> create(record, id))
>>> 3. Two methods called "put" and "add".
>> 
>> Agree with either (2) or (3).  I don't like (1) simply because I don't know
>> any other web API that uses that form, and I think we shouldn't break the
>> mold here.  Libraries certainly can, however.  Might prefer (3) over (2)
>> only because add is shorter than create.
> 
> I tend to prefer 3 over 2 as well. I would expect a function called
> 'create' to be some sort of factory function, like createElement,
> which obviously isn't the case here.
> 
> / Jonas
Received on Thursday, 17 June 2010 19:41:30 GMT

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