- From: Kris Zyp <kris@sitepen.com>
- Date: Mon, 10 May 2010 13:18:11 -0600
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps WG <public-webapps@w3.org>
-----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