Put request need created flag

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Put request need created flag

Kyaw Tun
I have hard to understand how to use add method effectively.

On my indexeddb wrapper library development, the wrapper database instance dispatches installable event for creating, deleting and updating a record. Interested components register and listen to update UI or sync to server. That requires differentiating created and updated on put call. On the otherhand add method throw Error rather than eventing onerror event when confict. So it usage will be very rare.

I wish put method request indicates some flag to differentiate between created or updated.

I could forget about put and use cursor directly, but still requires extra existance test request. 

Best 
Kyaw

Reply | Threaded
Open this post in threaded view
|

Re: Put request need created flag

Joshua Bell-3
On Wed, Nov 14, 2012 at 8:16 AM, Kyaw Tun <[hidden email]> wrote:
I have hard to understand how to use add method effectively.

On my indexeddb wrapper library development, the wrapper database instance dispatches installable event for creating, deleting and updating a record. Interested components register and listen to update UI or sync to server. That requires differentiating created and updated on put call. On the otherhand add method throw Error rather than eventing onerror event when confict. So it usage will be very rare.

I wish put method request indicates some flag to differentiate between created or updated.

I could forget about put and use cursor directly, but still requires extra existance test request. 

If we were to add this, it would be beneficial to retain the current default behavior of put(). It allows optimizations in some cases where no read-back is required.

The sync scenario is interesting, and there's been some (offline) discussion about an observer API that could, for example, observe a key range and receive a change list at the end of each transaction. This might also require knowing if a put() was a "change" or an "add", but such a cost would be opt-in, and could be avoided e.g. during initial loading of data.