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

When you get to the cursor, the object already existed. This is the case where the update occurs on an existing object and put means put because it already exists.

On Jun 16, 2010, at 11:19 AM, Mikeal Rogers wrote:

> I don't have an opinion about addOrModify but in the Firefox build I'm
> messing with the cursor has an update method that I find highly useful
> and efficient.
> 
> -Mikeal
> 
> 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. 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.
>> 
>> 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.
>> 
>> / Jonas
>> 
>>

Received on Wednesday, 16 June 2010 18:24:02 UTC