This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
IDBObjectStoreRequest/Sync.put currently takes an optional parameter "noOverwrite" But as was discussed in "[IndexedDB] Changing the default overwrite behavior of Put" [1] what we really need is a tri-state: only insert, only modify, or either. Maciej suggested we should just have 3 separate functions. This was re-iterated with Mozilla's proposal (well, 3 guys _from_ Mozilla's proposal :-) in ""[IndexDB] Proposal for async API changes" [2]. I think the current leading proposal naming wise is "add/modify/addOrModify". It's unfortunate that the common case (addOrModify) is the most verbose one, but as discussed in the second thread, it's the most clear set of names anyone's proposed so far. [1] http://www.mail-archive.com/public-webapps@w3.org/msg08646.html [2] http://www.mail-archive.com/public-webapps@w3.org/msg08825.html
Some feedback from Kris that should be taken into account: ---------- Forwarded message ---------- From: Kris Zyp <kris@sitepen.com> Date: Wed, May 19, 2010 at 1:45 PM Subject: [IndexedDB] Re: [Bug 9769] New: IDBObjectStoreRequest/Sync.put should be split into 3 methods To: "public-webapps@w3.org" <public-webapps@w3.org> I continue to believe that splitting put into 3 methods is a very shortsighted approach to dealing with put directives. We are currently looking at how to indicate whether or not to overwrite an existing record when putting data in the DB, but there certainly is the possibility that in the future there will be additional directives. Having used this API in server side JavaScript for some time, we already utilizing additional directives like version-number predicated and date predicated puts (for example, using this API to connect to CouchDB). Splitting into three methods doesn't provide an extensible path forward, and is overly targeted to a present impl. The most future-proof approach here is to define a second argument to put that takes a "directives" object, which currently specifies an "overwrite" property. Thus, the three states can be written: put(record, {overwrite: false}); // don't overwrite put(record, {overwrite: true}); // must overwrite/update put(record, {}); or put(record); // can do either And we have plenty of room for defining other directives in the future if need be. Kris
*** Bug 9698 has been marked as a duplicate of this bug. ***
9698 was dealing with the same underlying issue, so I'm merging it in here with this.
From an ensuing conversation on the email list: On Fri, Jun 11, 2010 at 12:16 AM, Jonas Sicking <jonas@sicking.cc> wrote: On Tue, May 25, 2010 at 9:03 AM, Kris Zyp <kris@sitepen.com> wrote: > If we were to move to three methods, could we at least call them > add/modify/put? Keeping the get, put, delete methods with REST > correspondence is extremely nice property of the API (both in terms of > consistency with familiar terms and ease of use in RESTful systems). For what it's worth, I would be fine with that.
Agree to splitting the put method in to two - put and putNoOverwrite
How was this agreed upon??? You posted your suggestion to the list and less than half a day later implemented it despite an on-going discussion on the list and no one agreeing with you.
So we currently have .put and .add. I think there was agreement on the list to this, but it's too long ago that I'm not fully sure. Can this bug be closed?