PatternQuery Upcoming Features

Pattern Queries are the basis for upcoming features. The current release is for Rapid Application Development, but the following features are in progress:

Rapid Application DevelopmentGather, distribute, transform, edit, or delete small or large Item structures with minimal application code. This is like a third intra-JVM database access API, along with ItemSpace and the InfinityDBMap. Application Java code includes PatternQuery definitions directly inline. This is next to be released.
Consistency MaintenanceApplication-transparent capturing and transformation of database modification operations keeps redundant data structures in synch. Applications are simplified and isolated from database structure alterations. It is possible to maintain consistent alternate views of data for the ultimate in performance, convenience and flexibility. (Future release)
Client QueriesClient code residing in various places such as IoTs or remote applications using Java, JavaScript, or Python can access a database through a controlled path called a Client Query. This path uses the REST feature of InfinityDB version 6. Each Client Query is an access point associated with a single PatternQuery definition that determines the actions taken by the REST access on behalf of the client code. Client code does not have full access to the database, but is isolated, to increase security and to future-proof against database structure changes as needed over time. For example, web pages can include JavaScript code to use AJAX to get to the REST interface where a Client Query executes. Each REST access sends a single request to the server and receives a single response through one of possibly multiple available Client Query access paths . (InfinityDB Client/Server future release).
Ad-Hoc queryUsers can interactively create, edit, execute, save, retrieve, and share simple but powerful interactive queries to find and transform data. For example, developers can test and perfect queries for embedding in applications. Also, client programs who have write access to a database can store a PatternQuery in it and execute it in order to perform complex operations local to the server at high speed. (InfinityDB Client/Server future release).


In order to upgrade a standalone Java application so that it continuously maintains the inversion we defined above for AircraftModel we can:

  • change the application’s Java Code, or
  • add or change the application’s PatternQueries by adding a result Item for the AircraftModel Items where the result already includes Aircraft Items, or
  • set up a PatternQueryItemSpace that intercepts the mutations to the database and transparently maintains the inverted forms of the Aircraft Items under AircraftModel. Any set of per-Item transformations such as permutations of Item data, even with joins is possible. The events can be either mutations of the Aircraft Items, the AircraftModel Items, or both.

An elegant way to handle the maintenance of the Item replications is to keep all the PatternQueries in the database itself. Then the application invokes them where they live, directly in the database, and they can be edited or copied from elsewhere in order to keep them in synch with the data structures. The database becomes a self-describing unit, with its structure and the operations it can perform against itself all in one place. The Java code can still contain some hard-coded parts, such as legacy code, as desired.

Alternatively, a PatternQueryItemSpace can transparently extend the hard-coded part or the other PatternQueries, by using a single per-database PatternQuery, whose definition is stored anywhere. The application constructs one PatternQueryItemSpace in order to wrap the database, and then does operations on it instead of on the database directly. In InfinityDB Client/Server, a special per-database PatternQuery is called the system query and is stored under ‘System Query’ (that’s the System EntityClass immediately followed by the Query EntityClass and then the PatternQuery definition). The PatternQuery sees an input stream of individual Items being inserted into or deleted from the wrapped database, and it rewrites them and can optionally join them with database Items to produce a set of output Items that actually reach the wrapped database. If the inputs are deletions, then the outputs are deletions as well.

Performance will not reach the high levels of direct InfinityDB access, of course, but it can be concurrent. There is a SimplePatternQueryItemSpace and an alternative ThreadedPatternQueryItemSpace. Both of them are implemented by wrapping a TriggerItemSpace that in turn wraps the wrapped ItemSpace. The PatternQuery definition affects the setup of the hidden TriggerItemSpace described below so that mostly only the necessary Items are captured and used, and the rest of the work is relatively fast.

For example, a system query could be:

System Query query {
    pattern =si {
        Aircraft =id1 model =model1;
        AircraftModel =model2 id =id2;
    result {
        Aircraft =id2 model =model2;
        AircraftModel =model1 id =id1;
    Where {
        'si' kind 'stream input';
        'id1' action 'union or difference';
        'model2' action 'union or difference;

With the above System Query, an insertion or deletion into the PatternQueryItemSpace of Aircraft '787' model 400 will match the first pattern, and then an Item AircraftModel 400 id '787 will be correspondingly inserted or deleted.

See Using PatternQueries and PatternQuery Implementation for more.