Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange Behaviour with Quotas (binary data) #228

Closed
keean opened this issue Nov 11, 2015 · 6 comments
Closed

Strange Behaviour with Quotas (binary data) #228

keean opened this issue Nov 11, 2015 · 6 comments

Comments

@keean
Copy link

keean commented Nov 11, 2015

I have an application that writes some large ArrayBuffers to IndexedDB, and I am using IndededDBShim to support versions of Safari that do not have IndexedDB support.

I am getting strange behaviour when writing objects larger than the WebSQL storage quota. If the user does not approve the storage size increment, then the 'put' transaction appears to succeed (it should be aborted). Then when I read the objectStore, I can find an item at the key, and read it. I get back a strange object, it looks to be an instance of 'Object' with no data, but it is not null, but neither is it the ArrayBuffer I tried to store.

The expected behaviour is that the transaction should be aborted, and the key should not exit in the objectStore.

@DibranMulder
Copy link
Contributor

Just leaving this here as a probable workaround, Thinkwise got a plugin that allows you to expand the default store size. This doesn't solve your issue though.

@keean
Copy link
Author

keean commented Nov 13, 2015

I have spent some time trying to find the problem, and it looks like it was to do with binary data (ArrayBuffers) in the JSON objects being stored. So I have added a work around that base64 encodes the array buffers, if it is using IndexedDBShim. It would be better (for compatibility with real IndexedDB) if IndexedDBshim would do this itself, although I can't think of an easy way to find where the binary data is. Looking at the PouchDB WebSQL driver, base64 may not be necessary, and you might only have to remove x0000, x0001, x0002, see: pouchdb/pouchdb#2900.

When I have removed the binary data, it now handles the quota correctly and aborts the transaction, and I can read the data back and validate it.

@brettz9 brettz9 added the Bug label Jun 17, 2016
@brettz9
Copy link
Collaborator

brettz9 commented Jun 17, 2016

A PR with test would be most welcome!

@brettz9 brettz9 changed the title Strange Behaviour with Quotas Strange Behaviour with Quotas (binary data) Oct 18, 2016
@brettz9
Copy link
Collaborator

brettz9 commented Oct 18, 2016

The ArrayBuffers or views on buffers (TypedArray or DataView) (support more recently added to IndexedDB) are not currently supported in IndexedDBShim (added now on the README as a known issue). A PR is most welcome!

@brettz9 brettz9 added this to the 4.0.0 milestone Jan 20, 2017
@brettz9
Copy link
Collaborator

brettz9 commented Feb 7, 2017

There had been some binary support previously, and internally now there is better potential support (e.g., for keys), but it is still not complete (nor are the parts that are complete fully tested).

But just one to-do I wanted to add mention of here while we're tracking binary--cloning should be done synchronously (in some places if not all) so that the API can report errors synchrously as expected by the spec (and W3C tests).

@brettz9
Copy link
Collaborator

brettz9 commented Feb 17, 2017

Support for ArrayBuffer, TypedArrays, and DataView has now been added with the latest commit to master. Also supported now are binary keys. However, #285 and #286 indicate two other items which tie into binary and which are not presently supported, and, as per other issues on the tracker, Safari still has some issues apparently and the polyfill.js that had been progressively fixing its support is almost certainly no longer working with the latest updates and will need to reflect the changes elsewhere as per #277 . However, as it appears the support for ArrayBuffer should fix this issue per #228 (comment) , I'll close this for now, though feel free to continue commenting further.

@brettz9 brettz9 closed this as completed Feb 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants