This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9769 - IDBObjectStoreRequest/Sync.put should be split into 3 methods
Summary: IDBObjectStoreRequest/Sync.put should be split into 3 methods
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Nikunj Mehta
QA Contact: public-webapps-bugzilla
: 9698 (view as bug list)
Depends on:
Reported: 2010-05-19 11:08 UTC by Jeremy Orlow
Modified: 2010-12-10 12:23 UTC (History)
5 users (show)

See Also:


Description Jeremy Orlow 2010-05-19 11:08:47 UTC
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.

Comment 1 Jeremy Orlow 2010-05-21 09:55:43 UTC
Some feedback from Kris that should be taken into account:

---------- Forwarded message ----------
From: Kris Zyp <>
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: "" <>

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.

Comment 2 Jeremy Orlow 2010-06-02 14:01:23 UTC
*** Bug 9698 has been marked as a duplicate of this bug. ***
Comment 3 Jeremy Orlow 2010-06-02 14:02:28 UTC
9698 was dealing with the same underlying issue, so I'm merging it in here with this.
Comment 4 Jeremy Orlow 2010-06-11 10:15:52 UTC
From an ensuing conversation on the email list:

On Fri, Jun 11, 2010 at 12:16 AM, Jonas Sicking <> wrote:
On Tue, May 25, 2010 at 9:03 AM, Kris Zyp <> 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.
Comment 5 Nikunj Mehta 2010-06-16 16:49:14 UTC
Agree to splitting the put method in to two - put and putNoOverwrite
Comment 6 Jeremy Orlow 2010-06-17 15:29:32 UTC
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.
Comment 7 Jonas Sicking (Not reading bugmail) 2010-11-08 12:00:58 UTC
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?