Use the following information to configure Query Accelerator. The query set configurations define the denormalized tables that will be created to support faster queries.
| Attribute | Description |
|---|---|
| version | The version of the query set. |
| name | The table name. The actual database table name will have a prefix of ‘alf_qs_’ and a suffix of ‘_v’ plus the version. So for a query set called of ‘test1’ and a version of 1 that actual database table name would be ‘alf_qs_test1_v1’. |
| properties | A collection of properties to appear on the denormalized table. A property consists of a name attribute which is the name of a property and an isIndex attribute which indicates that the related column on the table should be indexed. |
| aspects | A collection of aspects to appear on the denormalized table. The table will have a boolean column for each of the aspects to indicate if the node has those aspects applied. An aspect consists of a name attribute which is the name of an aspect and an isIndex attribute which indicates that the related column on the table should be indexed. |
| compositeIndexes | A collection of composite indexes to be created for the table. A composite index consists of an attribute where the attribute name is the index name and the attribute value is a collection of names of properties and/or aspects of the query set. |
- The maximum length of the query set name and the version is the maximum table name length of the database system being used, minus 9. So for Postgres, which has a maximum table name length of 63 bytes, the maximum name and version length in the query set is 54 bytes.
- Queries that include negations on aspects should not be accelerated.
- Properties of type MLTEXT are NOT supported. If included a WARN message will be logged, the properties will be ignored, and the corresponding denormalized table will be created without them.
- The denormalized table will have an alf_type column, holding the name of the content type.
- When aspects are used, the denormalized table will contain only the nodes that have at least one of the aspect. It is for this reason that a query checking for the absence of an aspect will not use the query accelerator and will be performed by the standard engine.
- Auditable properties (namely: cm:creator, cm:created, cm:modifier, cm:modified and cm:accessed) defined in the configuration will be ignored. Data of this nature is always available and there is no need to store it on the corresponding denormalised table.
- Properties of the following types defined in the configuration will be ignored. If
included a WARN message will be logged, as the properties are already included in
the denormalized table:
- cm:owner
- cm:noderef
- sys:node-dbid
- sys:node-uuid
- When files are read from the queryAccelerator.config.dir directory they are read in alphanumeric order. So 0101-coyote.json would be read before 0102-coyote.json and it is read before 0201-acme.json.