Re: Detailed review of 4.12. Client-side database storage

On Fri, 12 Oct 2007, Mihai Sucan wrote:
> 
> Change the specification, and base all the storage, on a single unified 
> approach. Let all the storage data be in SQL databases.
> 
> Keep the current definition of the client-side database storage API, 
> which allows developers to use SQL databases, and such. This the "raw" 
> access to all the storage of a domain.
> 
> However, to satisfy the needs and use-cases for globalStorage and 
> sessionStorage, define two basic tables within a single database. Let 
> the database name be the 'storage' string. Let the first table be 
> 'global'. Let the second table be 'session'. Now, define the format of 
> the two tables such that Web authors have the same features/capabilities 
> as they are now defined for globalStorage and sessionStorage APIs 
> (key/value columns, and the domain column for globalStorage).
> 
> Next, redefine the globalStorage and sessionStorage APIs to be just 
> "shorthands" to access the two SQL tables from the 'storage' database. 
> Define which SQL queries are automatically generated.

Given the way that Web Storage and the SQL-based database spec are going, 
it seems that this is not going to fly.


> I'd recommend to add some examples for executeSql().

I've since added a few, though not many. I'll add more if the spec gets 
more momentum again.


> > > Can binary data be stored in the database? Is the UA supposed to do 
> > > proper "escaping" for binary data arguments?
> > 
> > I'm not sure I follow. Could you elaborate?
> 
> Binary data, as in images, executables, videos, etc. can be inserted 
> into mySQL databases (and into other SQL databases, obviously). They 
> provide several field types which can handle hundreds of megabytes, even 
> gigabytes, of binary data. See BLOBs [1]
> 
> I was asking, if future UAs should allow inserting binary data into 
> tables.

We might add support for File objects in due course, but that would need 
us to spec the SQL dialect probably. Instead for now you can store Files 
in Web Storage and then store a pointer in the database. (You can't index 
on it then, of course, e.g. you can't do full-text search of attachments.)


> 1. Why complicate things with database versions? Any use cases?

Pretty much any serious use of this API will need to handle changing 
schemas while the app is running in multiple tabs, and this seems to be 
the simplest way of doing this.


> As I see, one can have database versions completely different, 
> independent, of each other. Actually, database versions are not really 
> "versions". They *can* be used as versions, but they can also be used as 
> ... something completely different.

No, there's only one set of data, it just has a version number associated 
with it so you don't try to read the old version with new code and, more 
importantly, vice versa.


> 2. Why openDatabase() instead of executeSql('SELECT databaseName') ?

There are three levels; getting a database, getting a transaction, and 
getting data. I don't think it makes sense to mix them.

Thanks, and sorry for taking years to reply,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 26 November 2009 00:07:30 UTC