[whatwg] Database feedback

On Wed, 26 Nov 2008, Jim Jewett wrote:
>
> I would name the question mark character aqt least once, so that it 
> can't be mistaken for a placeholder in the spec (rather than in the 
> SQL):
> 
> Where it now says:
> """
> Parse the first argument to the method (sqlStatement) as a SQL
> statement, with the exception that ? characters can be used in place
> of SQL literals in the statement. [SQL]
> """

Done.


> >> This still leaves open whether the statement has to actually be 
> >> PREPAREd, and whether other parameter types or host variables are 
> >> supported.
> > 
> > I'm not sure what you mean.
> 
> There are systems where you need to "prepare" a SQL statement before you 
> can execute it, but I think the current wording makes clear that this 
> system works from the strings, and does the PREPARE-ation itself as part 
> of execution.

Yeah, that's an implementation detail.


On Wed, 26 Nov 2008, Aaron Boodman wrote:
> On Wed, Nov 26, 2008 at 3:46 AM, Ian Hickson <ian at hixie.ch> wrote:
> > We could have a .writeTransaction() and a .readTransaction(), where 
> > the former always run in isolation.
> >
> > Any preferences?
> 
> My preference is for separating read transactions from write 
> transactions. Then the API could throw if you tried to write in a read 
> transaction.

On Wed, 3 Dec 2008, Scott Hess wrote:
> 
> In SQLite the lock is upgraded as-needed, and it does cause confusion. 
> The following can fail to get the write lock at the marked statement:
> 
>   BEGIN DEFERRED;
>      SELECT x, y, z FROM t WHERE q = ?;
>      INSERT INTO j VALUES (?, ?, ?);   -- *mark*
>   COMMIT;
> 
> In SQLite BEGIN is the same as BEGIN DEFERRED.  Gears changes the 
> default for BEGIN to BEGIN IMMEDIATE, which acquires the lock right 
> away.  If a developer wants to do a read-only transaction, they can 
> explicitly execute BEGIN DEFERRED.
> 
> In any case, my point is that upgrading mid-stream seems to be a point 
> of confusion for people.  You can explain what's happening, and they 
> will understand it, but the case comes up seldom enough that most people 
> never internalize it.  Requiring an explicit decision up front makes 
> things clear, and doesn't absurdly widen the API.
> 
> I would lean towards .transaction() and .readTransaction(), though. 
> Acquiring the lock immediately is almost always the right thing to do.
>
> You can code a join to get consistent data from multiple tables, but you 
> cannot code a single statement to insert data consistently into multiple 
> tables (ignoring triggers), which is why read-only explicit transactions 
> are rare, and write-only explicit transactions are common.  I'd say that 
> write-mostly transactions (one or two reads followed by a bunch of 
> writes) are probably also more common than read-only transactions.

On Wed, 26 Nov 2008, Jonas Sicking wrote:
> 
> I'm fine with either the perf-hit solution or the 
> .writeTransaction/.readTransaction solution. Both seems better than 
> having writes throw under basically race conditions. If we go with the 
> perf-hit solution we can always add the speedier 
> .writeTransaction/.readTransaction APIs in a later version.

I've introduced transaction()/readTransaction(), and made 
readTransaction() fail when executeSql() is called with a method that 
would mutate the database.


On Wed, 26 Nov 2008, Chris Prince wrote:
> > On Mon, 26 May 2008, Chris Prince wrote:
> >>
> >> // On the 1st call, this line means "create a database,
> >> // and set the version string to the empty string".
> >> var db1 = window.openDatabase("foo", "", "", "");
> >>
> >> // On the 2nd call, the meaning has changed to
> >> // "open the 'foo' database, regardless of the version string".
> >> var db2 = window.openDatabase("foo", "", "", "");
> 
> On Wed, Nov 26, 2008 at 3:46 AM, Ian Hickson <ian at hixie.ch> wrote:
> >
> > Yeah, that's a bit confusing. Not sure what to do about it.
> 
> Two ideas:
> 
> * Perhaps use a different value to mean "open any version, if one 
> exists".  Using 'null' seems like an obvious candidate.
> 
> * Alternately, don't allow the empty string as a valid version string. 
> Only use the empty string to mean "open existing".

Well the thing is that if the database doesn't exist, I still want the 
"open the database regardless of its version" case to actually open (and 
create) the database. The problem is what to use as the version string in 
that case.

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

Received on Monday, 29 December 2008 01:59:56 UTC