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.
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.
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).
If the data layer encountered an error when committing a transaction, then the error was ignored. Now all errors from the data layer which occur when cancelling or committing a transaction are passed to the end-user and displayed accordingly.
A new $method variable is now available in database events. The $method variable specifies the type of request that was made which triggered the event. Possible values are CREATE / UPDATE / DELETE.
If the field value was changed in the VALUE statement, then the context variables were not reset to reflect this change in the ASSERT statement. As a result the ASSERT would receive the old values prior to being affected by the VALUE statement.
