Re: [IndexedDB] Re: [Bug 9769] New: IDBObjectStoreRequest/Sync.put should be split into 3 methods

On Wed, May 19, 2010 at 5:45 AM, Kris Zyp <kris@sitepen.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.

I'm not sure I understand what other directives you're thinking about.
In any case it seems very strange to me to have a 'overwrite'
directive which has a default which is neither true or false. It would
be more understandable to me to have a real tri-state, or to use
something like

put(record, {forbidOverwrite: true}); // don't overwrite
put(record, {onlyOverwrite: true}); // must overwrite/update
put(record, {}); or put(record); // can do either

or some such.

However ultimately I feel like this directive will be used often
enough that it makes sense to create explicit API for it. The
implementation overhead of separate functions is really not that big,
and I can't see any usage overhead?

/ Jonas

Received on Saturday, 22 May 2010 00:17:17 UTC