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

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 10 May 2010 11:53:04 -0700
Cc: Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps WG <public-webapps@w3.org>
Message-id: <24B05CF8-0613-442E-9E77-6147522788DB@apple.com>
To: Kris Zyp <kris@sitepen.com>

On May 10, 2010, at 10:36 AM, Kris Zyp wrote:

> Hash: SHA1
> On 5/7/2010 1:32 PM, Shawn Wilsher wrote:
>> Hey all,
>> Per the current spec [1], noOverwrite defaults to false for put
>> operations on an object store.  Ben Turner and I have been
>> discussing changing the default of put to not allow overwriting by
>> default.  We feel this is better behavior because simply omitting
>> the flag should not result in destroying data.  Putting my
>> application developer hat on, I'd much rather have to be explicit
>> about destroying existing data instead of having it happen on
>> accident.  We could also change the parameter to just overwrite and
>> have it default to false.
>> What is everyone's thoughts on this?
> I believe there are three useful modes:
> overwrite: false - Must create a new record
> overwrite: true - Must overwrite/update an existing record
> (something else) - Create a new record or overwrite/update an existing
> (depending on the key of course).
> I would prefer that the last option should be indicated by omission of
> the overwrite property (and thus be the default). I don't buy the
> destruction of data argument, prior art clearly suggests that "put"
> can alter existing data (unless you explicitly indicate otherwise).

Instead of a mysterious boolean argument, how about three separate  
operations? "add()", "replace()" and "set()". I bet you can tell which  
is which of the above three behaviors just from reading the names,  
which is certainly not the case for a boolean argument. Having a  
boolean flag that changes a functions behavior tends to result in code  
that is hard to read and understand. Clearly named separate methods  
are better API design.

Received on Monday, 10 May 2010 18:53:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:07 UTC