Client side apps often have little hope of knowing in advance whether or not a query will return a result. Schema mismatches are a common occurrence. To counteract this, we can introduce the notion of "registered queries". These are a set of relational expressions which must type-resolve at all times. The set can be added to or deleted from during a transaction. If a registered query fails to resolve due to a database schema change, then the change must be rolled back. Thus, the registered query set represents a contract between the client and server- the server promises that all registered queries will be able to be run and return a relation result (instead of type error due to schema changes). When a client connects, he can validate that the registered queries are those which he expects, or he can reinstall them.
Note that these queries are not the same as "prepared statements" in other DBMSes. Some notable differences are:
registered queries' lifetimes extend beyond a single connection and are not associated with a client connection
ddl changes can be blocked by registered queries (because the notion of a registered query implies the intention to issue that query in the future)- thus, registered queries are effectively constraints on DDL changes
registered queries do not need placeholder variables because the queries are merely example queries to pin down the schema (though we could change this in the future)
in particular, Project:M36 could optimize the storage layout (pre-materialize results) to service this set of queries
Client side apps often have little hope of knowing in advance whether or not a query will return a result. Schema mismatches are a common occurrence. To counteract this, we can introduce the notion of "registered queries". These are a set of relational expressions which must type-resolve at all times. The set can be added to or deleted from during a transaction. If a registered query fails to resolve due to a database schema change, then the change must be rolled back. Thus, the registered query set represents a contract between the client and server- the server promises that all registered queries will be able to be run and return a relation result (instead of type error due to schema changes). When a client connects, he can validate that the registered queries are those which he expects, or he can reinstall them.
Note that these queries are not the same as "prepared statements" in other DBMSes. Some notable differences are:
Similarities include: