- From: Kris Zyp <kris@sitepen.com>
- Date: Wed, 19 May 2010 06:45:15 -0600
- To: "public-webapps@w3.org" <public-webapps@w3.org>
-----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