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

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

Kris

On 5/19/2010 5:08 AM, bugzilla@jessica.w3.org wrote:
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9769
>
> Summary: IDBObjectStoreRequest/Sync.put should be split into 3
> methods Product: WebAppsWG Version: unspecified Platform: All
> OS/Version: All Status: NEW Severity: normal Priority: P2
> Component: WebSimpleDB AssignedTo: nikunj.mehta@oracle.com
> ReportedBy: jorlow@chromium.org QAContact:
> member-webapi-cvs@w3.org CC: mike@w3.org, public-webapps@w3.org
>
>
> IDBObjectStoreRequest/Sync.put currently takes an optional
> parameter "noOverwrite"  But as was discussed in "[IndexedDB]
> Changing the default overwrite behavior of Put" [1] what we really
> need is a tri-state: only insert, only modify, or either.  Maciej
> suggested we should just have 3 separate functions.  This was
> re-iterated with Mozilla's proposal (well, 3 guys _from_ Mozilla's
> proposal :-) in ""[IndexDB] Proposal for async API changes" [2].
>
> I think the current leading proposal naming wise is
> "add/modify/addOrModify". It's unfortunate that the common case
> (addOrModify) is the most verbose one, but as discussed in the
> second thread, it's the most clear set of names anyone's proposed
> so far.
>
> [1]
> http://www.mail-archive.com/public-webapps@w3.org/msg08646.html [2]
> http://www.mail-archive.com/public-webapps@w3.org/msg08825.html
>

- -- 
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/
 
iEYEARECAAYFAkvz3VoACgkQ9VpNnHc4zAzovgCfSUuPkTaQkHROHZ3p4ngN80w3
P2kAnR88ksXy9F+gwI4/CfDHzllPvF+r
=RJlo
-----END PGP SIGNATURE-----

Received on Wednesday, 19 May 2010 12:46:40 UTC