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
