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

On Wed, Jun 16, 2010 at 11:08 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Jun 16, 2010 at 10:46 AM, Nikunj Mehta <nikunj@o-micron.com>
> wrote:
> >
> > On Jun 16, 2010, at 9:58 AM, Shawn Wilsher wrote:
> >
> >> On 6/16/2010 9:43 AM, Nikunj Mehta wrote:
> >>> There are three theoretical modes as you say. However, the second mode
> does not exist in practice. If you must overwrite, then you know that the
> record exists and hence don't need to specify that option.
> >> To be clear, you are saying that there are only two modes in practice:
> >> 1) add
> >> 2) add or modify
> >>
> >> But you don't believe that "modify" doesn't exist in practice?  In terms
> of SQL, these three concepts exists and get used all the time.  "add" maps
> to INSERT INTO, "add or modify" maps to INSERT OR REPLACE INTO, and "modify"
> maps to UPDATE.
> >
> > IndexedDB is not SQL, I think you would agree.
>

Sure.  But it's not BerkeleyDB either (even though it is much more
similar).  Lets stick to technical reasoning and not rhetoric, pleassseeeee.


> > UPDATE is useful when you replace on a column, by column basis and,
> hence, need to do a blind update. When updating a record in IndexedDB, you'd
> have to be certain about the state of the entire record. Hence, it makes
> sense to leave out UPDATE semantics in IndexedDB.
>

Very good point.


> I can't say that I have a strong sense of if "modify" is needed or
> not. On the surface if seems strange to leave out, but it's entirely
> possible that it isn't needed.
>
> Unless someone provides a good use case, I would be fine with leaving
> it out and seeing if people ask for it.
>

Me too.

On Wed, Jun 16, 2010 at 9:58 AM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:

>  So, in summary, I agree to splitting the put method in to two - put and
>> putNoOverwrite. I am also in favor of retaining the name as put (contrasted
>> with get). I would like to avoid bikeshedding on names even though there
>> have been ample opportunities on this list lately with that.
>>
> I think you are completely ignoring the arguments in this thread about the
> issues with naming it put.  I don't think it is bikeshedding; these seem
> like legitimate concerns.


Agreed.  We need to at least discuss whether aligning with REST is
important.  I don't care much either way, but you should at least give Kris
a chance to respond.

Also, if there are only 2 states (overwrite and noOverwrite) then a
parameter to put (rather than 2 functions) might still be the best approach.

J