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

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


On 5/10/2010 12:53 PM, Maciej Stachowiak wrote:
>
> 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.
>

I have been very fond of put() and it's nice correspondence with
RESTful nomenclature and behavior. The overwrite flag feels more like
a directive about how to do the put then a distinct operation.
Furthermore, I think it is very reasonable to expect that we could
potentially add more directives in the future. For example:
store.put({id:"foo", bar:3}, {
    overwrite: true,
    ifNotModifiedSince: lastKnownModificationTime, // maybe
conditional puts
    likelyToChangeSoon: true, // maybe optimization info
    likelyToBeReadSoon: false
});
Having a second argument that handle future directives as an object
hash seems like the most future-proof, extensible approach to me. And
this code doesn't look mysterious to me at least.

- -- 
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkvoW/MACgkQ9VpNnHc4zAyaQgCgh64/lUjMVESEym3Zdj7rsyZq
UhIAn20vAU9xBT09yqwSiRcoJjJP5BEa
=c1Wi
-----END PGP SIGNATURE-----

Received on Monday, 10 May 2010 19:19:29 UTC