- From: Nikunj Mehta <nikunj@o-micron.com>
- Date: Wed, 16 Jun 2010 10:46:01 -0700
- To: Shawn Wilsher <sdwilsh@mozilla.com>
- Cc: Kris Zyp <kris@sitepen.com>, public-webapps WG <public-webapps@w3.org>
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. > >> 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. > > Cheers, > > Shawn >
Received on Wednesday, 16 June 2010 17:46:39 UTC