Re: Web Storage & SQL

On Apr 9, 2009, at 8:19 AM, Boris Zbarsky wrote:

> Giovanni Campagna wrote:
>> So why not adding a parameter on openDatabase() to specify what kind
>> of database we want (and what kind of query language we will use)?
>> I mean something like
>> openDatabase(name, version, type, displayName, estimatedSize)
>> where type can be any string
>> so, for example, type = "sql" uses the standard SQL, type="sqlite"
>> uses SQLite extensions, type="-vendor-xyz" is a vendor specific
>> extension, etc.
>
> How does this solve the original "no such thing as standard SQL,  
> really" issue?

I agree that "no such thing as standard SQL" (or rather the fact that  
implementations all have extensions and divergences from the spec) is  
a problem. But I am not sure inventing a brand new query language and  
database model as proposed by Vlad is a good solution to this problem.  
A few thoughts off the cuff in no particular order:

1) Applications are starting to be deployed which use the SQL-based  
storage API, such as the mobile version of GMail. So it may be too  
late for us to remove SQL storage from WebKit entirely. If we want  
this content to interoperate with non-WebKit-based user agents, then  
we will ultimately need a clear spec for the SQL dialect to use, even  
if we also added an OODB or a relational database using some other  
query language.

2) It's true that the server side code for many Web sites uses an  
object-relational mapping layer. However, so far as I know, very few  
use an actual OODB. Relational databases are dominant in the market  
and OODBs are a rarely used niche product. Thus, I question Vlad's  
suggestion than a client-side OODB would sufficiently meet the needs  
of authors. Rather, we should make sure that the platform supports  
adding an object-relational mapping on top of SQL storage.

3) It's not obvious to me that designing and clearly specifying a  
brand new query language would be easier than specifying a dialect of  
SQL. Note that this may require implementations to actually parse  
queries themselves and possibly change them, to ensure that the  
accepted syntax and semantics conform to the dialect. We are ok with  
this.

4) It's not obvious to me that writing a spec for a query language  
with (afaik) a single implementation, such as jLINQ, is easier than  
writing a clear and correct spec for "what SQLite does" or some subset  
thereof.

Thus, I think the best path forward is to spec a particular SQL  
dialect, even though that task may be boring and unpleasant and not as  
fun as inventing a new kind of database.

Regards,
Maciej

Received on Thursday, 9 April 2009 19:53:07 UTC