3 ms·

This ignores the fact that SQL already has standards with multiple implementations and is very well established. You can have a basic portable subset - the prob

• derefr 4y ago
  Standards are for platform implementors. Developers inevitably ignore standards, and instead code "empirically" to whatever the implementation they're developing against is willing to expose—both in terms of features (guaranteed by the standard or not), and in terms of bugs. (Yes, those devs are doing a bad thing. They should only obey the letter of the standard, and not "look through" to what the implementation is doing. But we can't just intentionally break support for the stuff they build through this empirical-discovery-of-features-and-bugs process. That would just hurt the innocent users who just want to access their websites — which might very well be abandonware by the point that we discover and fix whatever standard-nonconformance bug such sites relied upon.) What we can do to control developer behavior, is to impose incentives. If there are multiple implementations of the standard in popular use in different browsers, each with different bugs, then developers will feel the need to support those different browsers, and so will test in them, find where the deviations from the standard cause breakage, and so end up coding portably. But if all the implementations in use in different browsers have the same bugs (perhaps because they're all actually the same implementation), then even supporting multiple browsers won't do anything to break people's assumption on those bugs; and so people will write brittle code that depends on exactly those bugs being present to work, and will break even if the platform implementor just upgrades the implementation to a newer version without the bug. This is the "bug-for-bug compatibility" that Microsoft worries so much about across Windows versions. It's a royal PITA to support, and W3C/WHATWG/etc have thusfar assiduously avoided allowing anything into the standards which has only one implementation, and therefore which devs could ever "lock onto" the bugs of with brittle implementations. --- Also, this ignores that most of the "pragmatics" of managing a SQL DBMS are not specified by the SQL standard. SQL is not as standard as people think it is! ANSI SQL is mostly concerned with specifying how DML queries work; the DDL stuff is almost entirely a mess of implementation-defined syntax that happens to share some conventions, but with no standards guarantees. Check this out: https://www.postgresql.org/docs/current/sql-createindex.html#id-1.9.3.69.9 https://www.postgresql.org/docs/current/sql-createindex.html... > CREATE INDEX is a PostgreSQL language extension. There are no provisions for indexes in the SQL standard. Do you really want to expose a SQL API where you can't create indices, because there's no portable syntax for creating indices? Would such an API even be useful? If we really wanted a "web SQL API", the designers of said API couldn't just lean on the existing SQL standard; they would actually have to standardize what "web SQL" syntax is themselves — probably as a superset of ANSI SQL, but still laying out a bunch of additional requirements. It'd be similar in scope to WebGL. That's a big ask. And even if they did that, that'd likely mean that they'd end up with no existing implementations of the standard! (Because it's not like you'd want to lock in all of SQLite's nonstandard DDL syntax choices as "the" WebSQL syntax, right? You'd want to think these out "from first principles", considering what's most "implementation-neutral.")
  • yyyk 4y ago
    I don't think there was so much risk of relying on db behaviour much less bugs. There's a DML standard, breaking it would have had massive consequences far beyond the web platform - we could have relied on SQLite being broadly compatible within the simple INSERT/UPDATE/DELETE/SELECT subset (I think more could have been done, but this is enough for a start). As for DDL, not much was initially required beyond CREATE TABLE, CREATE VIEW and CREATE (UNIQUE) INDEX (which in practice have a basic common syntax). IMHO the ask was not anywhere as complex as WebGL.
• acdha 4y ago
  > This ignores the fact that SQL already has standards with multiple implementations and is very well established. You can have a basic portable subset - the problem was already very well specified at the offline level. This is only partially true, as you can see from the many apps which only support one SQL database even if they're using something like an ORM which is ostensibly portable. Sometimes that's caused by use of things like using extensions but in other cases it can be caused by differences in things like data validation and conversion or how transactions are processed. That doesn't mean that portability is impossible but everyone doing it seriously tests continuously against multiple implementations to make sure they aren't inadvertently introducing a dependency on one flavor. Both SQLite and MySQL are especially notorious for this because you'd have cases where code which was invalid would either be automagically converted (hopefully to what you wanted) or the error silently suppressed so you'd have code which only works, for example, on a database where DATE can be "0000-00-00". As simple example, at the time Web SQL was proposed as a standard, SQLite did not support foreign key checks at all. It still does not implement full Unicode support so you'd have to require all implementations enable that extension with the same configuration or you'd have data-dependent application bugs. I would not personally have minded terribly if SQLite was effectively standardized like this but I understand why people wanted to see n>1 implementations. The browser developers are going to be supporting things for many years and as soon as a new feature launches any and all behaviors it exposes will become an API which has to be managed carefully to avoid breaking someone's production application.