[whatwg] Some comments/questions on database storage

[Brady Eidson]

Many of these points I have no response to and would like to hear  
Ian's take.

For some points, I have answers based on my current understanding...

On Feb 25, 2008, at 12:56 PM, Ralf Stoltze wrote:

> - In 4.3.2, the spec defines the concept of origin, with respect to
> script elements. However, the term is also used in combination with
> browsing contexts and databases. 4.11.2 says: "Each origin has an
> associated set of databases."
>
> So what is the origin of a database?
> - the originating host of the script which creates a database?
> - the origin of the document that script belongs to?
...
> - cont'd:
> "this database feature is limited to scripts running with the same
> origin as the database."
>
> Seems like my English is too limited here. What does "running with"
> mean?
> - the originating host of the script?
> - the origin of the document that script belongs to?
>
> Again, this comes down to defining the origin of a database.

We've had the assumption that the origin is with the associated  
browsing context, and therefore the document the script belongs to.
Clarification would be great...

> - 4.11.3 defines that placeholders simply have to be replaced with
> values from the arguments array. As I understand, this does not per se
> ban SQL injections. Will the spec define *how* to replace  
> placeholders,
> including how to escape and quote values?

Placeholders are the mechanism the spec mandates to prevent SQL  
injections et al.  *How* seems to be an implementation detail.
SQLite, for example, has the ? + argument structure in place already.

> - From 4.11.3:
> "A mostly arbitrary limit of five megabytes per origin is  
> recommended."
>
> The session/local storage part defines a quota on a per domain  
> basis. Is
> there any reason for this inconsistency (since both specs are now  
> based
> on the origin model)? Circumventing origin restrictions with  
> subdomains
> is the same for local storage and database storage.

I believe Ian had an explanation for this when it was raised earlier  
on this list, but can't remember what it was.  :)  Would like to hear  
it again.

> - I've seen some discussion on this list regarding the order of
> execution of statements within one transaction. However, I believe  
> that
> this was related to an older version of the spec (which had implicit
> transactions?).
>
> Based on 4.11.6, step 6.7, I assume the following snippet to always
> execute in order 1, 2, 3?
>
> db.transaction(function(tx) {
>  tx.executeSql('query 1', null, function(tx, rs) {
>    tx.executeSql('query 2', null, function(tx, rs) {
>    });
>  });
>  tx.executeSql('query 3', null, function(tx, rs) {
>  });
> });

4.11.3 step 6 states that if an executeSql call passed steps 1-5, the  
statement is queued up in the transaction.
4.11.6 step 6.7 says "move on to the next statement, if any"
I trust this means "the next statement in the transaction's statement  
queue" and that the queue pops statements in the order they were queued.

This means that query 1 would be queued, query 3 would be queued, then  
in the callback for query 1, query 2 would be queued.
Execution order 1, 3, 2

If a javascript engine was truly interruptible, query 1 completed  
before query 3 was queued, and the engine for some reason decided to  
run the query 1 callback before query 3 was scheduled, the order would  
end up 1, 2, 3 - but I don't see that happening with any current JS  
implementation, and I don't know what ECMAScript 4 says about the  
future of JS in this regard.

~Brady