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:

> -----BEGIN PGP SIGNED MESSAGE-----
> 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.

Regards,
Maciej
Received on Monday, 10 May 2010 18:53:39 GMT

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