DAP4: DAP4 Filter Constraints
Background
One of the unaddressed issues for sequences is the degree to which they should support relational operators, and specifically joins and equivalent operations such as selections involving multiple sequences.
Some time ago, in one of our telecons, someone (Nathan?) proposed the idea of forcing all complex relational queries to be pre-built on the server. The idea was that this would allow the server to limit relational queries to those that could be performed in a computationally efficient and secure fashion.
I am making a proposal for an alternative to complex client-specified queries under the assumption that we adopt the idea of pre-defined server-side queries.
Proposal
First, I assume that all complex queries are pre-built on the server in the form of server-side functions.
Under this assumption, I would then propose that we replace the DAP2 selection constraint with a "filter" constraint. I deliberately use the term "filter" instead of "selection" to indicate its more limited semantics.
The filter is a predicate over the fields of a sequence record. In effect it specifies a subset of sequence records to transmit to the client. When the predicate applied to a record evaluates to true, the record is tranmitted, otherwise it is suppressed.
The proposed syntax for filters is as follows:
<sequence-variable-name> | <filter-predicate>
The '|' can be read as "such that".
The syntax of the filter predicate would be a standard expression where the atomic (leaf) elements of the predicate would be either fields of the sequence record or constants. The allowed operators would be boolean (&& || !), comparison (= != > < >= <=) and arithmetic (+ - * / %). I do not think there is any syntactic ambiguity here, but to be sure, we could require the filter predicate to be enclosed in parentheses.
Discussion
The advantage of the filter approach is that it should be a lot easier to implement than more complex queries; it certainly would be easier to implement than the DAP2 select constraints.
I hypothesize that the filter mechanism would be capable of representing most of the real-world examples that have been encountered in DAP2.
Note that limiting complex queries to be encapsulated in server side functions is without loss of generality since someone could be so foolish as to define a server-side function that took a full SQL query as an argument and executed it on the server.
