Bug 18807 – Support storing JavaScript objects as BLOB

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebCore Misc.

[Jayant Sai]

According to http://www.sqlite.org/datatype3.html, 'BLOB. The value is a blob of data, stored exactly as it was input.'. Currently in WebKit & Safari, the implementation seems to convert the JavaScript object to a string "[object Object]". It would be great if it were possible to store JavaScript objects and JSON objects within the database as BLOB and as objects and not as string representations.

Currently, only a string de/serialization would work, but that can be expensive, especially when trying to run Safari on iPhone which has very limited JavaScript execution time.

[Jayant Sai]

Created attachment 20897 [details]
Test page

A simple test page showing storing an object literal as BLOB. Currently the alert displays the type of data after SELECT as string.

[Alexey Proskuryakov]

SQLite documentation is only tangentially related to HTML5 storage, because there are at least two other type systems to consider - first, there is JavaScript, and then, there is DOM. And anyway, BLOB is not magic - it's just a special kind of string suitable for storing large amounts of data.

Yet, it does seem a little weird that a function is stringified like "[object Object]" in this test case - e.g. alert(selectData) successfully shows its source, and one could expect the same here.

[Jayant Sai]

Thank you for clarifying about the SQLite & HTML5 storage differences.

Do you have any recommendations on how I should store the object, without converting it to a String. In my current app, this conversion takes too long. Or is this a bug which will need to be fixed in WebKit?

thanks
Jayant

(In reply to comment #2)
> SQLite documentation is only tangentially related to HTML5 storage, because
> there are at least two other type systems to consider - first, there is
> JavaScript, and then, there is DOM. And anyway, BLOB is not magic - it's just a
> special kind of string suitable for storing large amounts of data.
> 
> Yet, it does seem a little weird that a function is stringified like "[object
> Object]" in this test case - e.g. alert(selectData) successfully shows its
> source, and one could expect the same here.
> 

[Alexey Proskuryakov]

I don't think there is any way to store an object without turning it into a string. You may want to join WHATWG <http://www.whatwg.org/> and describe your use case in an e-mail to its list for people working on the specification to consider it.

Brady, what do you think? Does our implicit stringification appear broken, as I wondered in comment 2?

[Oliver Hunt]

JSON.stringify would appear to accomplish what is being requested here

[Oliver Hunt]

(In reply to comment #5)
> JSON.stringify would appear to accomplish what is being requested here

As an addendum, our postMesage serialisation is a flat binary storage system that supports  avariety of dom objects and allows cyclic graphs, maybe that would be superior?

[Anne van Kesteren]

This should be standardized first as suggested above. But also, as suggested above, there's ample alternatives available.