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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
 

On 5/24/2010 2:10 PM, Jonas Sicking wrote:
> On Fri, May 21, 2010 at 6:59 PM, Kris Zyp <kris@sitepen.com> wrote:
>>> 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.
>
> Couldn't you always simply call addOrModify (or whatever we'll end up
> calling it)? Given that neither localStorage or WebSQLDatabase
> supports 'forbid overwrite' inserts it seems like this should work?
>
>> Don't assume that the API will only be consumed.
>
> Definitely. The API is definitely intended to be consumable by
> libraries. In fact, I suspect that will be the case more often than
> not. I'm not really sure that I'm following how the proposed API is
> library un-friendly?
>
> / Jonas

A quick example of what I mean by the wrapper pattern we have been
using a lot:

// A store wrapper that adds auto-assignment of attribution properties
to a store
function Attribution(store){
    return {
        put: function(record, directives){
            record.updatedBy = currentUser;
            record.updatedAt = new Date();
            return store.put(record, directives);
        },
        get: store.get.bind(store),
        delete: store.delete.bind(store),
        openCursor: store.openCursor.bind(store),
    };
}

Obviously if there are three methods it makes every wrapper more
complicated.

If we were to move to three methods, could we at least call them
add/modify/put? Keeping the get, put, delete methods with REST
correspondence is extremely nice property of the API (both in terms of
consistency with familiar terms and ease of use in RESTful systems).

- -- 
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/
 
iEYEARECAAYFAkv79LcACgkQ9VpNnHc4zAwTpwCfaYoaDRu07REGTTPgmC6SBQec
pr0An0RmyQBmOchw5m1coz6h4Pf4Mtju
=1OuE
-----END PGP SIGNATURE-----

Received on Tuesday, 25 May 2010 16:03:49 UTC