It is now possible to run multiple query expressions when an event on a table has occured. Query expressions can be separated with a semicolon, and will be run in the same transaction as the main query.
When using encryption, the expected value (once encrypted) would never be the same as the encrypted value in the storage layer. As a result, it would never be possible to putC or delC a KV item.
Now the mysql package first gets the key from the storage layer, and then checks it’s decrypted value, before attempting to overwirte the value in the storage layer.
All request variables which are assigned to an sql query are now specified in one location, ensuring that they are consistent and always present for all queries.
It is now possible to run queries when a user signs-up or signs-in, by specifying multiple queries within an ON SIGNUP (…) clause, or a ON SIGNIN (...) clause.
Previously if a field had a type, and a value was entered which did not match that type, then an error was raised, even though the ASSERT clause was not set. Now the field will be set to nil if the field does not match the specified type, and the ASSERT clause can be used to ensure that a valid value is always entered.
It is now possible to set a variable on a connection, and use that variable in multiple subsequent queries. This ensures that websockets can make use of state variables for detecting logged-in, and non-logged-in clients.
Ther is no need to return all auth data when caling the Info() and Auth(token) rpc functions. Instead only the id needs to be returned to the consuming application.
Remove the need to query a particular KV level, and instead use slightly different encoded keys, and use prefix based iteration. This means we can use different KV stores to give the same functionality, without needing to use hierarchical KV stores.
We don’t need to check whether the record already exists, as we always have any record contents when we are procesing a document. Therefore we already know if a document exists or not in the kv store.
Websocket notifications were cleared/flushed regardless of whether individual statements were successful or not.
Now notifications are shifted onto the stack, or removed if the statement is unsuccessful. Once the full query has been processed, all pending notifications are flushed to all websockets (ignoring the current connection frin which th query originated).
