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

-----BEGIN PGP SIGNED MESSAGE-----
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:
>> -----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.
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
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/
 
iEYEARECAAYFAkv3OnMACgkQ9VpNnHc4zAxAjQCgltPHlvYbnXCS23VFYnvgbv2+
u6cAnArShTsEkai7/w7uhKuAyVsLKHR4
=svK6
-----END PGP SIGNATURE-----

Received on Saturday, 22 May 2010 01:59:35 UTC