Here is a leisurely overview of the PatternQuery feature of InfinityDB Server. The PatternQuery reference is very detailed, and there are also examples of PatternQueries here and in the demo/readonly database in each server. REST APIs with PatternQueries has example code for creating dynamic, simple or intricate interfaces with very little code at the client end.
Since time began for programming (effectively just before the unix epoch 00:00:00 Jan 1 1970 GMT), programmers have talked about declarative programming as the ultimate goal, and how hard the current method is – procedural programming. Procedural means algorithms and the whole idea of a program having a ‘current state’ that moves along forwards or backwards as the execution proceeds, with variables, loops, if statements, and so on. The idea of declarative programming is that there is no such moving pointer into the code, just statements that describe what is wanted. There would be no reason to fret over the transitions in the state of the algorithm at various points during the execution, but instead only one single statement, executed all at once. For a DBMS, the input is the state of the database and the parameters, the output is the desired information or data transformation.
SQL is a declarative language for database access, and has been enormously successful as a result. SQL has no algorithms, no current execution point, no variables, no loops, no if statements and so on. SQL is therefor accessible to a vastly wider range of people than software engineers. Once compiled, an SQL statement always completes, at least in principle. The only debugging needed is to refine the query and re-execute.
PatternQueries are for declarative database access as well, but can do far more than SQL, taking declarative programming one step further. It is possible to write simple queries just to retrieve data, like SQL, but also one can write much more complex queries that encroach on the generality of algorithms and procedures. An individual PatternQuery can gather, validate, transform, compute or distribute data with diverse sources and destinations from multiple intra-database and external locations. A PatternQuery can act like a complete application by itself for some tasks, with no procedural glue code, with simple, obvious structure, and with a very small efficient definition.
Simple Hierarchical Data
PatternQueries operate not only on tables, but also on a hierarchical generalization of tables called an ‘ItemSpace’, which is very flexible and simple, yet which can represent almost anything. A database structured in an ItemSpace can easily be extended at any time in small increments – unlike strict tables, which enforce a single rarely modified structure called a ‘schema’. When changed, a tabular schema can force large sections of applications to be rewritten, or even abandoned. This feature of the ItemSpace is called ‘late binding’. A late binding database can also do what an early binding database is forced to do, but the reverse is not true.
Simple Fast Execution
PatternQueries begin to run almost instantaneously and are efficient, because the ItemSpace can be configured for speed. Structures in an ItemSpace can effectively be ‘pre-computed’ portions of the query, which are analogous to the expensive SQL ‘materialized join’ but which are completely dynamic instead. Because of this capability, the PatternQuery has far less work to do, and can begin execution in tens of microseconds, not seconds to minutes, and some queries complete almost immediately. SQL has to solve a terrific riddle on each query, involving a combinatorially difficult process of choosing indexes, join methods, the execution order of the joins, temporary space allocation and more. PatternQuery instead just rewrites the query to handle joins and other issues immediately.
Patterns and Symbols
Results and Symbols
The output of the query is as simple as the input. One merely provides one or more ‘results’, each of which is a branch on the result tree. Again, there are literals, expressions, and symbols. Each result corresponds to one more ‘Item’ or ‘fact’ that is added to or removed from the database, and it can plug in or compute with the values that were assigned to the pattern symbols each time a match occurs. For example an expression embedded in a result could be (quantity * price + shipping). A result ‘fires’ when the matching of the patterns reaches a point where the symbol values necessary for the result are determined. Because there can be unlimited results, the database can be added to or updated in unlimited ways, whereas SQL can only have a single kind of effect on or return a single table at a time. Each result symbol has an ‘action’ which determines how it deals with its data: it can copy, move, union, difference, and more. So a PatternQuery is like a whole collection of SQL statements at once, and it is more like a small tidy ‘application’ than a simple query. When SQL is embedded in an application, multiple SQL statements are executed for any task, mixed in with procedural code that moves data into and out of the SQL queries and does some computations – an expensive, rigid mess.
Symbols are much more than designators of unknowns in patterns and knowns in results. Each can be defined in a ‘Where table’ to have certain simple attributes that affect the meaning. For example, a symbol can be told to match only the first or last possibility, or at most 10 or a value greater than a given value. The dozen or so possible symbol attributes, such as the minimum or ‘from’ attribute, can have values that are also literals, expressions, or symbols. This allows fantastic expressive richness, producing a possible network of relationships between symbols. Some such networks are ‘uncomputable’ because they create circular definitions, but if not, then anything is allowed, as long as expressions do not violate the ‘strong typing’ rules for intermediate computations which are there to prevent certain errors in advance. These networks are declarative nevertheless, and one can read the query as a simple statement of the acceptable relationships and computations. The symbol networks define the query in a way that can maximize performance far beyond that provided by boolean filter expressions.
As powerful as the symbol networks are, multi-step computations are still needed sometimes. A ‘reducer’ is a kind of symbol that can perform computations over series of pattern matches, accumulating results as the matching goes along. The reducer can refer to its state on the previous match, and update that state. Reducers are sequential like procedural programs, and can achieve many similar goals, but the definition of the reducer in the query is declarative, and there is no concept of a ‘current execution point’ or loops, if statements, variables and so on. The reducer (which is a ‘recursive function’ to be precise) simply describes in one place a transformation between two successive states, with input from any other part of the query to be combined with each transformation. So it participates in the network of symbol relationships, adding yet more richness without any non-declarative code. One reads the reducer as an ‘input’ and ‘output transformation between two states in combination with other symbol or expression values.
For simplicity, many predefined reducers are provided, such as count, sum, mean, variance, sigma, hash, and so on. There are also timers and randomizers. Each of these is is a different ‘symbol kind’, and there are many kinds of symbol. Each kind can be told to reset itself dependent on the pattern matching of portions of the pattern tree, or to summarize by omitting the output up to the last iteration, and other clearly understandable things dependent on a few general purpose symbol attributes.
Multiple Inputs and Outputs and Client Queries
So for REST access, a single PatternQuery acts like a little application program, serving requests via a designated access URL. Each request causes the PatternQuery to be re-compiled and re-executed. This ‘client query’ can gather database data, process it, validate it, output database data, and deal with the request and response headers and content.. No special procedural code is necessary. Simply because of the flexibility of the ItemSpace, a client PatternQuery can choose to get and store data representing sensor input, control system output, human data entry and data return, database state, and so on, all integrated into one overall operation.
The internals of PatternQuery are invisible to the PatternQuery author entirely, and there are no configuration files, installation procedures, tuning, administrator maintenance or other issues at all. Yet, the system uses many advanced techniques for high performance and features. It is based on the InfinityDB database engine, a tried and true, robust, fast hierarchical DBMS. Special hidden algorithms include ‘zig-zag join’, pattern rewriting for optimization using topological sorting and transitive symbol resolution, expression pre-compiling, predicate push-down, symbol re-ordering, range and literal access optimization and more. These features and more are invisible to a PatternQuery author except in reaching far higher performance in many situations.
See for Yourself
To get deeper, see PatternQueries, then see PatternQuery Reference for a full explanation of the details. A set of examples may be what you need to get a feel for it at PatternQuery Examples. If you are an RDBMS guru, there are some elementary explanations of the internals at PatternQuery Implementation. Contact us at email@example.com for more. We can provide you access to the sandbox at the infinitydb.com server to experiment with, and to your own database as well. You can also launch your own server on Amazon AWS Marketplace for total isolation, security, and administration capability – just search for InfinityDB.