Re: Web Storage & SQL

On Thu, Apr 9, 2009 at 12:52 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> 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.

I tend to agree with Maciej here.

There's lots of competence and experience with SQL out there. And
there's something to be said for the fact that SQL has proven itself
as a usable language at this point. I doubt that we could design a
language that cover as many use cases as well as SQL does. Though of
course we might be able to still be able to follow the 80% rule if we
design our own language.

But I definitely think that we need to define a strict SQL dialect to
use. One that will probably be stricter than SQLite currently is to
allow for easy implementation with other SQL backends.

/ Jonas

Received on Thursday, 9 April 2009 20:29:09 UTC