W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

RE: CfC: to publish the First Public Working Draft of Web Database spec; deadline 7 September

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 1 Dec 2009 01:53:50 +0000 (UTC)
To: public-webapps <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.62.0912010136100.4718@hixie.dreamhostps.com>
On Tue, 1 Sep 2009, Laxmi Narsimha Rao Oruganti wrote:
> 
> - Expecting a single writer model is not the way the relational 
> databases have been designed.  Note: Neither Microsoft Jet nor Microsoft 
> SQL CE exhibit this behavior.  The right way (read: ANSI way) is to have 
> isolation levels for transactions.  I am happy to restrict the number of 
> isolation levels to be supported are limited to what SQLite supports.  
> Namely, ReadCommitted and Serializable.  On the other hand, it might be 
> good idea to have a connection level parameter/knob to say it is a read 
> only connection Vs. read-write connection.

Could you elaborate on how this could be exposed without exposing scripts 
to race conditions?


> - I am a new bee to web programming.  However, not having the ability to 
> control when to commit or when to rollback is little uncomfortable.  It 
> is as uncomfortable as treating the local storage as cookie and have UA 
> clear it whenever it wishes (there is thread going on this local storage 
> being treated as bookmark cache Vs. cookie cache).  In terms of scenario 
> or use case, think about shopping cart web site.  I am going thru a list 
> of products.  I have added some of the products to shopping cart, but 
> then I realized that the total amount is exceeding the limit I have in 
> my mind.  In this case, I would like go and drop some of the products to 
> bring the total value to limit I have in my mind.  In this case, I don't 
> think User Agent should open another transaction to execute 'DELETE' 
> statements.

There can be no user interaction interleaved with transactions (well, 
unless you do something pretty crazy where you do dummy SELECTs while 
waiting for user input with the async API, but I don't think we should be 
even remotely encouraging that!).

So I don't think that use case makes sense here.


> - SQL as the query language is a hard one to bet on as almost all 
> databases have failed to be compliant.  Be it SQLite, SQL CE, BDB.  All 
> have tried to stick to a behavior set by some existing products like SQL 
> Server or Oracle or Sybase.  I can quote some examples to prove that 
> compliance is not achieved in SQL world, but I defer that to keep this 
> mail short.  In fact, this spec itself did not start to put SQL query 
> language stuff because of the same standardization issues.  "[SQL] The 
> precise dialect has not yet been specified."

"not yet" being the operative term. If there is interest from any vendors 
other than those using Sqlite, I'll be happy to spec the precise dialect 
required for interop.


> Before we make this as a public working draft, I would like to see the 
> spec become multi database vendor friendly. Today the spec reflects 
> SQLite architecture which is against the basic value system of 
> standards.  I am sure you guys would also agree with me that standards 
> are there to promote multiple vendors and provide a platform for healthy 
> competition.

I agree that it would be better if the spec defined the precise dialect of 
SQL to be supported. However, unless doing this would mean Microsoft and 
Mozilla would be willing to implement this API, it seems like a lot of 
work for minimal benefit.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 1 December 2009 01:54:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT