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

[Nikunj Mehta]

Would be useful to bear in mind the semantics of the two methods:

1. If storing a record in an index that allows multiple values for a single key,
  a. add is going to store an extra record for an existing key, if it exists.
  b. put is also going to store a new record for the existing key, if it exists.
  c. add is going to store the first record for a key, if it doesn't exist.
  d. put is also going to store the first record for the key, if it doesn't 
exist.
2. If storing a record in an object store or an index that allows a single 
value per key,
  a. add is going to store the record for a key, if it doesn't exist.
  b. put is going to update the existing record for the key, or create a new 
record if one doesn't exist for the key.

Only cursor operations can be used to update the value of a record once stored 
in a multi-value index.

Nikunj
On Jun 17, 2010, at 10:40 AM, Jonas Sicking wrote:

> On Thu, Jun 17, 2010 at 10:33 AM, Shawn Wilsher  wrote:
>> On 6/17/2010 10:26 AM, Kris Zyp wrote:
>>> 
>>> My order of preference:
>>> 1. parameter-based:
>>> put(record, {id: "some-id", overwrite: false, ... other parameters ..});
>>> This leaves room for future parameters without a long positional
>>> optional parameter list, which becomes terribly confusing and
>>> difficult to read. In Dojo we generally try to avoid more than 2 or 3
>>> positional parameters at most before going to named parameters, we
>>> also avoid negatives as much as possible as they generally introduce
>>> confusion (like noOverwrite).
>>> 2. Two methods called "put" and "create" (i.e. put(record, id) or
>>> create(record, id))
>>> 3. Two methods called "put" and "add".
>> 
>> Agree with either (2) or (3).  I don't like (1) simply because I don't know
>> any other web API that uses that form, and I think we shouldn't break the
>> mold here.  Libraries certainly can, however.  Might prefer (3) over (2)
>> only because add is shorter than create.
> 
> I tend to prefer 3 over 2 as well. I would expect a function called
> 'create' to be some sort of factory function, like createElement,
> which obviously isn't the case here.
> 
> / Jonas

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

[Jonas Sicking]

On Thu, Jun 17, 2010 at 10:33 AM, Shawn Wilsher  wrote:
> On 6/17/2010 10:26 AM, Kris Zyp wrote:
>>
>> My order of preference:
>> 1. parameter-based:
>> put(record, {id: "some-id", overwrite: false, ... other parameters ..});
>> This leaves room for future parameters without a long positional
>> optional parameter list, which becomes terribly confusing and
>> difficult to read. In Dojo we generally try to avoid more than 2 or 3
>> positional parameters at most before going to named parameters, we
>> also avoid negatives as much as possible as they generally introduce
>> confusion (like noOverwrite).
>> 2. Two methods called "put" and "create" (i.e. put(record, id) or
>> create(record, id))
>> 3. Two methods called "put" and "add".
>
> Agree with either (2) or (3).  I don't like (1) simply because I don't know
> any other web API that uses that form, and I think we shouldn't break the
> mold here.  Libraries certainly can, however.  Might prefer (3) over (2)
> only because add is shorter than create.

I tend to prefer 3 over 2 as well. I would expect a function called
'create' to be some sort of factory function, like createElement,
which obviously isn't the case here.

/ Jonas

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

[Shawn Wilsher]

On 6/17/2010 10:26 AM, Kris Zyp wrote:

My order of preference:
1. parameter-based:
put(record, {id: "some-id", overwrite: false, ... other parameters ..});
This leaves room for future parameters without a long positional
optional parameter list, which becomes terribly confusing and
difficult to read. In Dojo we generally try to avoid more than 2 or 3
positional parameters at most before going to named parameters, we
also avoid negatives as much as possible as they generally introduce
confusion (like noOverwrite).
2. Two methods called "put" and "create" (i.e. put(record, id) or
create(record, id))
3. Two methods called "put" and "add".
Agree with either (2) or (3).  I don't like (1) simply because I don't 
know any other web API that uses that form, and I think we shouldn't 
break the mold here.  Libraries certainly can, however.  Might prefer 
(3) over (2) only because add is shorter than create.


Cheers,

Shawn



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 6/17/2010 10:24 AM, Jeremy Orlow wrote:
>
> On Wed, Jun 16, 2010 at 9:58 AM, Shawn Wilsher  > 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.

My order of preference:
1. parameter-based:
put(record, {id: "some-id", overwrite: false, ... other parameters ..});
This leaves room for future parameters without a long positional
optional parameter list, which becomes terribly confusing and
difficult to read. In Dojo we generally try to avoid more than 2 or 3
positional parameters at most before going to named parameters, we
also avoid negatives as much as possible as they generally introduce
confusion (like noOverwrite).
2. Two methods called "put" and "create" (i.e. put(record, id) or
create(record, id))
3. Two methods called "put" and "add".

Is putNoOverwrite seriously a suggestion? That's sounds like a
terrible name to me.

- -- 
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkwaWsEACgkQ9VpNnHc4zAxxmQCfSVxfyo6OiutdKdYRcRFKz5DD
7QYAnjxuUgHkuMbeLjPYCWYvi2iDCWio
=b/if
-END PGP SIGNATURE-

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

[Jeremy Orlow]

On Wed, Jun 16, 2010 at 11:08 AM, Jonas Sicking  wrote:

> On Wed, Jun 16, 2010 at 10:46 AM, Nikunj Mehta 
> 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, pleassse.


> > 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  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

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

[Nikunj Mehta]

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  wrote:
>> On Wed, Jun 16, 2010 at 10:46 AM, Nikunj Mehta  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
>> 
>> 

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

[Mikeal Rogers]

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  wrote:
> On Wed, Jun 16, 2010 at 10:46 AM, Nikunj Mehta  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
>
>

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

[Jonas Sicking]

On Wed, Jun 16, 2010 at 10:46 AM, Nikunj Mehta  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

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

[Nikunj Mehta]

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
> 

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

[Shawn Wilsher]

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.



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



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Nikunj Mehta]

On May 10, 2010, at 10:36 AM, Kris Zyp wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 5/7/2010 1:32 PM, Shawn Wilsher wrote:
>> Hey all,
>> 
>> Per the current spec [1], noOverwrite defaults to false for put
>> operations on an object store.  Ben Turner and I have been
>> discussing changing the default of put to not allow overwriting by
>> default.  We feel this is better behavior because simply omitting
>> the flag should not result in destroying data.  Putting my
>> application developer hat on, I'd much rather have to be explicit
>> about destroying existing data instead of having it happen on
>> accident.  We could also change the parameter to just overwrite and
>> have it default to false.
>> 
>> What is everyone's thoughts on this?
> 
> I believe there are three useful modes:
> overwrite: false - Must create a new record
> overwrite: true - Must overwrite/update an existing record
> (something else) - Create a new record or overwrite/update an existing
> (depending on the key of course).
> 

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. 

I have two precedents to go by:
1. It is extremely rare that people call PUT with If-None-Match: * in HTTP.
2. Berkeley DB does not sport putMustOverwrite.

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 would prefer that the last option should be indicated by omission of
> the overwrite property (and thus be the default). I don't buy the
> destruction of data argument, prior art clearly suggests that "put"
> can alter existing data (unless you explicitly indicate otherwise).
> 
> Thanks,
> 
> - -- 
> Kris Zyp
> SitePen
> (503) 806-1841
> http://sitepen.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkvoRAAACgkQ9VpNnHc4zAxtPgCgnpmjx9aXWwS4SEPBegr6p9iI
> dsEAni3Yb9fbZRhdHxhYB+hVu5xhFwvo
> =UzZ9
> -END PGP SIGNATURE-
> 
> 

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

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 5/10/2010 12:53 PM, Maciej Stachowiak wrote:
>
> On May 10, 2010, at 10:36 AM, Kris Zyp wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 5/7/2010 1:32 PM, Shawn Wilsher wrote:
>>> Hey all,
>>>
>>> Per the current spec [1], noOverwrite defaults to false for
>>> put operations on an object store.  Ben Turner and I have been
>>> discussing changing the default of put to not allow overwriting
>>> by default.  We feel this is better behavior because simply
>>> omitting the flag should not result in destroying data.
>>> Putting my application developer hat on, I'd much rather have
>>> to be explicit about destroying existing data instead of having
>>> it happen on accident.  We could also change the parameter to
>>> just overwrite and have it default to false.
>>>
>>> What is everyone's thoughts on this?
>>
>> I believe there are three useful modes: overwrite: false - Must
>> create a new record overwrite: true - Must overwrite/update an
>> existing record (something else) - Create a new record or
>> overwrite/update an existing (depending on the key of course).
>>
>> I would prefer that the last option should be indicated by
>> omission of the overwrite property (and thus be the default). I
>> don't buy the destruction of data argument, prior art clearly
>> suggests that "put" can alter existing data (unless you
>> explicitly indicate otherwise).
>
> Instead of a mysterious boolean argument, how about three separate
> operations? "add()", "replace()" and "set()". I bet you can tell
> which is which of the above three behaviors just from reading the
> names, which is certainly not the case for a boolean argument.
> Having a boolean flag that changes a functions behavior tends to
> result in code that is hard to read and understand. Clearly named
> separate methods are better API design.
>

I have been very fond of put() and it's nice correspondence with
RESTful nomenclature and behavior. The overwrite flag feels more like
a directive about how to do the put then a distinct operation.
Furthermore, I think it is very reasonable to expect that we could
potentially add more directives in the future. For example:
store.put({id:"foo", bar:3}, {
overwrite: true,
ifNotModifiedSince: lastKnownModificationTime, // maybe
conditional puts
likelyToChangeSoon: true, // maybe optimization info
likelyToBeReadSoon: false
});
Having a second argument that handle future directives as an object
hash seems like the most future-proof, extensible approach to me. And
this code doesn't look mysterious to me at least.

- -- 
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkvoW/MACgkQ9VpNnHc4zAyaQgCgh64/lUjMVESEym3Zdj7rsyZq
UhIAn20vAU9xBT09yqwSiRcoJjJP5BEa
=c1Wi
-END PGP SIGNATURE-

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

[Maciej Stachowiak]

On May 10, 2010, at 10:36 AM, Kris Zyp wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 5/7/2010 1:32 PM, Shawn Wilsher wrote:

Hey all,

Per the current spec [1], noOverwrite defaults to false for put
operations on an object store.  Ben Turner and I have been
discussing changing the default of put to not allow overwriting by
default.  We feel this is better behavior because simply omitting
the flag should not result in destroying data.  Putting my
application developer hat on, I'd much rather have to be explicit
about destroying existing data instead of having it happen on
accident.  We could also change the parameter to just overwrite and
have it default to false.

What is everyone's thoughts on this?


I believe there are three useful modes:
overwrite: false - Must create a new record
overwrite: true - Must overwrite/update an existing record
(something else) - Create a new record or overwrite/update an existing
(depending on the key of course).

I would prefer that the last option should be indicated by omission of
the overwrite property (and thus be the default). I don't buy the
destruction of data argument, prior art clearly suggests that "put"
can alter existing data (unless you explicitly indicate otherwise).


Instead of a mysterious boolean argument, how about three separate  
operations? "add()", "replace()" and "set()". I bet you can tell which  
is which of the above three behaviors just from reading the names,  
which is certainly not the case for a boolean argument. Having a  
boolean flag that changes a functions behavior tends to result in code  
that is hard to read and understand. Clearly named separate methods  
are better API design.


Regards,
Maciej

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

[Shawn Wilsher]

On 5/10/2010 10:36 AM, Kris Zyp wrote:

I believe there are three useful modes:
overwrite: false - Must create a new record
overwrite: true - Must overwrite/update an existing record
(something else) - Create a new record or overwrite/update an existing
(depending on the key of course).
FWIW, right now the last two cases are the same (at least, how I'm 
reading the spec).


Cheers,

Shawn



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 5/7/2010 1:32 PM, Shawn Wilsher wrote:
> Hey all,
>
> Per the current spec [1], noOverwrite defaults to false for put
> operations on an object store.  Ben Turner and I have been
> discussing changing the default of put to not allow overwriting by
> default.  We feel this is better behavior because simply omitting
> the flag should not result in destroying data.  Putting my
> application developer hat on, I'd much rather have to be explicit
> about destroying existing data instead of having it happen on
> accident.  We could also change the parameter to just overwrite and
> have it default to false.
>
> What is everyone's thoughts on this?

I believe there are three useful modes:
overwrite: false - Must create a new record
overwrite: true - Must overwrite/update an existing record
(something else) - Create a new record or overwrite/update an existing
(depending on the key of course).

I would prefer that the last option should be indicated by omission of
the overwrite property (and thus be the default). I don't buy the
destruction of data argument, prior art clearly suggests that "put"
can alter existing data (unless you explicitly indicate otherwise).

Thanks,

- -- 
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkvoRAAACgkQ9VpNnHc4zAxtPgCgnpmjx9aXWwS4SEPBegr6p9iI
dsEAni3Yb9fbZRhdHxhYB+hVu5xhFwvo
=UzZ9
-END PGP SIGNATURE-

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

[Shawn Wilsher]

On 5/10/2010 1:33 AM, Jeremy Orlow wrote:

Either sounds fine to me.  Please open something in the bug tracker?
Filed bug 9698 [1] on changing noOverwrite to overwrite.  I'm going to 
wait to file a bug about changing the default until we get more feedback.


Cheers,

Shawn

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9698



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Vivek Khurana]

On Sat, May 8, 2010 at 1:02 AM, Shawn Wilsher  wrote:
> Hey all,
>
> Per the current spec [1], noOverwrite defaults to false for put operations
> on an object store.  Ben Turner and I have been discussing changing the
> default of put to not allow overwriting by default.  We feel this is better
> behavior because simply omitting the flag should not result in destroying
> data.  Putting my application developer hat on, I'd much rather have to be
> explicit about destroying existing data instead of having it happen on
> accident.  We could also change the parameter to just overwrite and have it
> default to false.
>
> What is everyone's thoughts on this?

 I will agree with you. I think PUT operation should not be allowed to
overwrite in any circumstances. If you want to overwrite the data
object, use POST.

regards
Vivek

-- 
The hidden harmony is better than the obvious!!

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

[Jeremy Orlow]

Either sounds fine to me.  Please open something in the bug tracker?

On Fri, May 7, 2010 at 10:12 PM, ben turner  wrote:

> I think that switching 'noOverwrite' from false to true is confusing.
> I definitely vote to rename the parameter to 'overwrite' and and keep
> the default as false.
>
> -Ben
>
> On Fri, May 7, 2010 at 12:32 PM, Shawn Wilsher 
> wrote:
> > Hey all,
> >
> > Per the current spec [1], noOverwrite defaults to false for put
> operations
> > on an object store.  Ben Turner and I have been discussing changing the
> > default of put to not allow overwriting by default.  We feel this is
> better
> > behavior because simply omitting the flag should not result in destroying
> > data.  Putting my application developer hat on, I'd much rather have to
> be
> > explicit about destroying existing data instead of having it happen on
> > accident.  We could also change the parameter to just overwrite and have
> it
> > default to false.
> >
> > What is everyone's thoughts on this?
> >
> > Cheers,
> >
> > Shawn
> >
> >
>
>

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

[ben turner]

I think that switching 'noOverwrite' from false to true is confusing.
I definitely vote to rename the parameter to 'overwrite' and and keep
the default as false.

-Ben

On Fri, May 7, 2010 at 12:32 PM, Shawn Wilsher  wrote:
> Hey all,
>
> Per the current spec [1], noOverwrite defaults to false for put operations
> on an object store.  Ben Turner and I have been discussing changing the
> default of put to not allow overwriting by default.  We feel this is better
> behavior because simply omitting the flag should not result in destroying
> data.  Putting my application developer hat on, I'd much rather have to be
> explicit about destroying existing data instead of having it happen on
> accident.  We could also change the parameter to just overwrite and have it
> default to false.
>
> What is everyone's thoughts on this?
>
> Cheers,
>
> Shawn
>
>

[IndexedDB] Changing the default overwrite behavior of Put

[Shawn Wilsher]

Hey all,

Per the current spec [1], noOverwrite defaults to false for put 
operations on an object store.  Ben Turner and I have been discussing 
changing the default of put to not allow overwriting by default.  We 
feel this is better behavior because simply omitting the flag should not 
result in destroying data.  Putting my application developer hat on, I'd 
much rather have to be explicit about destroying existing data instead 
of having it happen on accident.  We could also change the parameter to 
just overwrite and have it default to false.


What is everyone's thoughts on this?

Cheers,

Shawn



smime.p7s
Description: S/MIME Cryptographic Signature