4 ms·

If that's your definition then it's even more dumb to hold up Google Cloud Spanner as an example of how SQL gives you consistency. There's NO WAY to mutate Spa

If that's your definition then it's even more dumb to hold up Google Cloud Spanner as an example of how SQL gives you consistency. There's NO WAY to mutate Spanner tables via SQL. All writes are performed via the lower-level RPC interfaces. The only thing you can do with Spanner from SQL is query it. The consistency provided by Spanner is clearly not provided by SQL.

derefr 8y ago
Even if a DBMS only exposes read-only SQL support, that still has consistency-model implications—namely that, if you can execute several SQL statements in a transaction with a long delay between those statements, then all the statements in the transaction should execute against the same MVCC "version" of the affected tables. So a write on that lower-level RPC interface shouldn't, by the SQL spec, be able to cause a sequence of SQL wire messages like this: BEGIN SELECT COUNT(*) FROM foo; -- 100s later SELECT COUNT(*) FROM foo; COMMIT; ...to return separate numbers for those two SELECTs. If it could, under Spanner, then Spanner wouldn't be conformant to [the read-only subset] of whatever SQL standard it claims to obey. But, according to the Cloud Spanner docs (https://cloud.google.com/spanner/docs/transactions#read-only_transactions https://cloud.google.com/spanner/docs/transactions#read-only...), the above code will always return the same values for the two queries. And, if you're feeling argumentative, you could interpret the reason for the particular consistency semantics, as the fact that Cloud Spanner claims to support SQL, and SQL mandates that consistency. You could suppose that, without that claim, Cloud Spanner would never have bothered building a transactional MVCC layer into their architecture.
- ebikelaw 8y ago
  Unfortunately, no. Spanner may garbage collect the snapshot timestamp to which your example query was bound, if the garbage collection policy was triggered by additional writes at greater timestamps, or by the simple passage of time. The result of the second query may be a permanent error indicating that your data has disappeared. Spanner had a transactional MVCC system in their original implementation described in the 2012 paper which predates SQL support described in the 2017 paper. Therefore it is probably wrong to credit SQL with Spanner's MVCC system.
  - derefr 8y ago
    > The result of the second query may be a permanent error indicating that your data has disappeared. That's actually okay, per SQL. Any SQL transaction may fail, for any reason, at the server's discretion. Because the user's permission to operate on the table was revoked in the middle of their transaction, for example. Or because the server is going down and wants to drop connections. SQL clients have to be written to assume that any transaction could enter a failed state "before" the execution of a statement, even if the previous statement returned a success. Helpfully, though, they know that 1. by the SQL standard, that failure means that no part of the transaction applied; and 2. that this failure-state is a failure of the transaction context to be valid, rather than a failure of their statement to be valid. (They don't know that their statement is valid, but they know that they haven't been told that it isn't.)

derefr 8y ago

Even if a DBMS only exposes read-only SQL support, that still has consistency-model implications—namely that, if you can execute several SQL statements in a transaction with a long delay between those statements, then all the statements in the transaction should execute against the same MVCC "version" of the affected tables. So a write on that lower-level RPC interface shouldn't, by the SQL spec, be able to cause a sequence of SQL wire messages like this: BEGIN SELECT COUNT(*) FROM foo; -- 100s later SELECT COUNT(*) FROM foo; COMMIT; ...to return separate numbers for those two SELECTs. If it could, under Spanner, then Spanner wouldn't be conformant to [the read-only subset] of whatever SQL standard it claims to obey. But, according to the Cloud Spanner docs (https://cloud.google.com/spanner/docs/transactions#read-only_transactions https://cloud.google.com/spanner/docs/transactions#read-only...), the above code will always return the same values for the two queries. And, if you're feeling argumentative, you could interpret the reason for the particular consistency semantics, as the fact that Cloud Spanner claims to support SQL, and SQL mandates that consistency. You could suppose that, without that claim, Cloud Spanner would never have bothered building a transactional MVCC layer into their architecture.

ebikelaw 8y ago
Unfortunately, no. Spanner may garbage collect the snapshot timestamp to which your example query was bound, if the garbage collection policy was triggered by additional writes at greater timestamps, or by the simple passage of time. The result of the second query may be a permanent error indicating that your data has disappeared. Spanner had a transactional MVCC system in their original implementation described in the 2012 paper which predates SQL support described in the 2017 paper. Therefore it is probably wrong to credit SQL with Spanner's MVCC system.
- derefr 8y ago
  > The result of the second query may be a permanent error indicating that your data has disappeared. That's actually okay, per SQL. Any SQL transaction may fail, for any reason, at the server's discretion. Because the user's permission to operate on the table was revoked in the middle of their transaction, for example. Or because the server is going down and wants to drop connections. SQL clients have to be written to assume that any transaction could enter a failed state "before" the execution of a statement, even if the previous statement returned a success. Helpfully, though, they know that 1. by the SQL standard, that failure means that no part of the transaction applied; and 2. that this failure-state is a failure of the transaction context to be valid, rather than a failure of their statement to be valid. (They don't know that their statement is valid, but they know that they haven't been told that it isn't.)