W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

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

From: Kris Zyp <kris@sitepen.com>
Date: Fri, 21 May 2010 19:59:15 -0600
Message-ID: <4BF73A73.40005@sitepen.com>
To: Jonas Sicking <jonas@sicking.cc>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
Hash: SHA1

On 5/21/2010 6:16 PM, Jonas Sicking wrote:
> On Wed, May 19, 2010 at 5:45 AM, Kris Zyp <kris@sitepen.com>
> wrote:
>> 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.
Some ideas for possible future directives:
put(record, {
    ifNotModifiedSince: timeStampWhenIRetrievedGotTheData,
    ifVersionNumber: versionNumberIRetrievedGotTheData,
    useNewAndImprovedStructuralCloning: true,
    vendorExtensionIndicatingKeepInMemoryCacheForFastAccess: true,
    encryptOnDisk: true,
    storeCompressedIfPossible: true});
Just some ideas. The point is that there are numerous possible
directives and we certainly can't foresee all of them, so we shouldn't
be limiting ourselves. And overwrite seems like it is a great example
of a directive and we can start with a good precedent for adding new ones.

> 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,
I was implying that it was tri-state, undefined being the third (and
default) state indicating that the DB could either overwrite or
create. I certainly don't mind a different tri-state scheme though.
But at least using true and false seems pretty intuitive (and doing
either seems like a good default).

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

I am not too concerned about the implementation. But, as we been using
this API in SSJS, we have been increasingly using a wrapper pattern,
wrapping low-level stores with additional functionality that exposes
the same API. Wrappers add functionality such as caching, data change
notifications, extra validation, and so. The more methods that are
exposed the more difficult it is wrap stores. Don't assume that the
API will only be consumed.

- -- 
Kris Zyp
(503) 806-1841
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Received on Saturday, 22 May 2010 01:59:35 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:25 UTC