Re: Web Storage & SQL

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Maciej Stachowiak 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.
First, OODB's seem to be on the rise, albiet under different titles
lately (AppEngine, SimpleDB, CouchDB, Persevere). Second, when using
relational DBs, most devs use ORMs to interact with the DB, so they
are primarily working in the object-realm, even on the server. For
situations where data is transferred to the client (in data form),
devs stay in the object realm for the data transfer (JSON) and on the
browser in JavaScript. I don't see why we would want to force data
translation back to the relational realm in the last leg on the
browser when we have worked so hard to stay within object paradigm.

>
> 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.
I agree that we shouldn't be specifying a brand new query language. I
thought the idea was looking at existing query languages that would be
better fits for the web/JS environment. Nothing new would need to be
invented here.
>
> 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.
JSONPath/JSONQuery seems like a far more mature path if an alternative
to SQL is to be considered, and has a pretty good set of
implementations (probably at least 5 different impls).

> 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.

In view of point #1, this may be the best course, I don't know, but I
mainly wanted to correct some of the statements above.

- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iEYEARECAAYFAkneW+oACgkQ9VpNnHc4zAzs7wCeNh6qFrbomEi/wsx2FXo5GoQG
kKgAn35tW9U3iUzBoeYhfmgq9eBphoU7
=G5bP
-----END PGP SIGNATURE-----

Received on Thursday, 9 April 2009 20:36:32 UTC