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 k...@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-
Re: [IndexedDB] Re: [Bug 9769] New: IDBObjectStoreRequest/Sync.put should be split into 3 methods
On Fri, May 21, 2010 at 6:59 PM, Kris Zyp k...@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
Re: [IndexedDB] Re: [Bug 9769] New: IDBObjectStoreRequest/Sync.put should be split into 3 methods
On Wed, May 19, 2010 at 5:45 AM, Kris Zyp k...@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.
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, 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?
/ Jonas
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 k...@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-
[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, bugzi...@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.me...@oracle.com
ReportedBy: jor...@chromium.org QAContact:
member-webapi-...@w3.org CC: m...@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-
