Defines the maximum number of snapshot queries (one per thread) within a partition that are executed at once. This attribute overrides the same attribute defined in the table's tablespace.
Defines the number of table partitions, and the number parallel regions used to scan a table during the snapshot portion of a query. This attribute overrides the same attribute defined in the table's tablespace.
Expression (or reference to expr-macro) to be applied on incoming row updates. You cannot use update-rule in a field that is designated as a primary key.
Path to the sbapp or sbint file from which to import the schema. The path is relative to the project root (where the top-level lvconf must reside). If you specify a simple file name, LiveView searches for the file on the current project's module search path.
An optional rule specifying a predicate that is evaluated against the data in any incoming insert or update. If the incoming data satisfies the predicate and a row with a matching primary key exists, then no update occurs and the row is deleted. If the incoming data satisfies the predicate and no row with a matching primary key exists, then no insert occurs. If the incoming data does not satisfy the predicate, then an insert or update occurs as normal.
An optional rule specifying a predicate that is evaluated against this table. The predicate is used to register a query against the table where the rows added to the result set are deleted through the publish data path. For this reason, the predicate usually has a time component (see WHEN and FOR). Also see row-delete-rule. For more general table trimming see Alerts and the Delete rows action
Typed variables can be defined that will be used in the table-level rules. Use these to save intermediate calculations which otherwise would have to be re-calculated.
An optional preprocessor-chain defines one or more preprocessors that intercept incoming data to the table, transform it, then pass it along to the table. The current version supports only one preprocessor.
A preprocessing app that intercepts data going into the table, processes it, and forwards it to the table. Currently only one preprocessor is supported.
There are certain unusual situations where a start-up artifact from a preprocessing app is not available early in LiveView server start-up. In these rare cases, in order to allow LiveView to run, you can skip typechecking of the referenced preprocessing app by setting this attribute to false. The downside is that you will no longer receive compile-time typecheck warnings, and may get runtime exceptions if your configuration is wrong.
Since StreamBase applications can have container connections defined within them, it is possible to have a container connection from this application to another LiveView table. Explicitly stating these dependencies here allows LiveView to know about them such that LiveView will load tables in the proper order on startup.
When a new row or update is happening on the local table, the join preprocessor can look up a row in a foreign table, based on its primary key, to augment the information in the local row.
A table join can be half-active or full active. For a half-active join of two tables, a local table and a foreign table, when a row in the local table is inserted or updated, a lookup of a row in the foreign table is performed based on the join keys, and the lookup results update the data in the local row. A full-active join performs an update of the local table when either the local or the foreign table is updated.
A valid output stream of the application to receive data from.
Application streams that are intended to send data to LiveView or receive data from LiveView must be marked public; that is, the stream property "Always expose Stream for Dequeue" or "Always expose Stream for Enqueue" must be set.
When a table is configured with snapshot-parallelism, setting this attribute to true pushes the processing of this aggregation into the same parallel region as snapshot processing. In general, performance should be better by running inside the parallel region. If a particular aggregate function specified in the configuration cannot be run in parallel, this setting is ignored.
The group name(s) or aliase(s) must be a primary key field of this table. By default, the base table has column name(s) that match this tables primary key(s) will be used as group by keys.
The pivot for clause is used to provide a pivot column if any literals are used in the values clause. Each literal in the values clause is interpreted as the value for the pivot column
The values clause should have comma separated values where each value can either be a literal or an expression resulting in the boolean value. If even a single value is literal, the for clause becomes mandatory
A transform is a transformation of the data from another table. Unlike an aggregation, the transform does not combine multiple rows from the other table. It can be used to add calculated fields, to modify fields, or to filter out unwanted rows.
Under normal circumstances, cycles in the configuration graph are not allowed. Under certain advanced cases it might be necessary to have a cycle in the graph. A simple example would be table A publishing to table B and table B publishing back to table A. If a scenario like this is required, a custom transform should be introduced and the “allow-cycle” attribute should be set to true. This setting should be made with great care.
There are certain unusual situations where a start-up artifact from a preprocessing app is not available early in LiveView server start-up. In these rare cases, in order to allow LiveView to run, you can skip typechecking of the referenced preprocessing app by setting this attribute to false. The downside is that you will no longer receive compile-time typecheck warnings, and may get runtime exceptions if your configuration is wrong. If typechecking is enabled, the system attempts to coerce fields to be the correct type, such as converting an integer to a long, or filling in empty fields with null.
When a table is configured with snapshot-parallelism, setting this attribute to true pushes the processing of this transform into the same parallel region as snapshot processing. In general, performance should be better by running inside the parallel region.
The Java class that implements TableProvider and will manage the connection to some remote source of tables. This field is required if you have specified a type of custom-table-provider.
Defines the maximum number of snapshot queries (one per thread) within a partition that are executed at once. This attribute overrides the same attribute defined in the table's tablespace.
Defines the number of table partitions, and the number parallel regions used to scan a table during the snapshot portion of a query. This attribute overrides the same attribute defined in the table's tablespace.
This setting applies to all table types, and is used to specify in milliseconds the amount of delay before publishing data from the table; this condition is known as conflation of data. Set this attribute to a positive, non-zero integer ≥ 5 to specify conflation for this table. A value below 5, including zero and all negative numbers, is forced equal to 5. Static aggregation tables have an internal setting that is the equivalent of setting publish-interval-millis=1000 (1 second). For such tables, you cannot disable conflation, but you can change the conflation interval by setting publish-interval-millis to a different integer value. For all other table types, specify a value for publish-interval-millis to both enable conflation and to specify the conflation interval. To disable conflation for non-aggregation tables, remove the publish-interval-millis attribute entirely from your table’s lvconf entry.
Without conflation, data is published from a table as soon as it is received. With conflation enabled, all downstream components see conflated data, including alerts, LiveView Desktop, clients built with the Java or .NET APIs, or another table in a transformation sequence. If an alert is set for a conflated table, be aware that it is possible for conditions that would otherwise trigger an alert to occur briefly during a conflation period; in this case, the trigger conditions are conflated away and the alert does not trigger. See the Data Conflation topic in the LiveView Reference Guide for further information.
Configuring a StreamBase global application at this level allows you to specify parameters one time and then reference the global application within other configuration areas in LiveView. For example, one or more tables can be configured to receive data from this global application. Streams that are intended to send data to LiveView or receive data from LiveView must be marked public; that is, the stream property "Always expose Stream for Dequeue" or "Always expose Stream for Enqueue" must be set.
An application cam be placed in a sub-folder of the main project root; if so, this attribute specifies the folder name. Make sure this folder is on the project's module search path.
An expr-macro allows you to specify an expression once and reference it elsewhere in LiveView configuration. The expression can optionally contain embedded parameters identifiable by a dollar sign prefix within the expression. The parameters must also be formally declared in the XML configuration and can have optional default values. The macro can then be called in other applicable LiveView configuration files using a function syntax. The applicable areas would be anywhere that an expression can be specified, with comma-separated argument values in parentheses.
For example: <insert-rule>MyMacro(3, 4)</insert-rule>
Macros cannot be combined within expressions and cannot be nested. For example, the following are NOT valid:<insert-rule>MyMacro(3)+MyMacro(4) </insert-rule> <expr-macro id="MyMacro"><expr>SumIf($x+$y)</expr><parameters><parameter name="x"/><parameter default-value="2" name="y"/></parameters></expr-macro>
Parameters can be specified for a macro. Parameters are embedded into the macro expr by prefixing them with a dollar sign (for example, $myParam). Macros are called with positional parameter specification (for example, myMacro(paramVal)).
Optional default value for this parameter. Since parameters are fulfilled in order, if one parameter is unspecified (using the default), then all parameters after it must also be left unspecified.
Optional setting for optimizing the cache size used for storing query predicates against a table in this table-space. The size is allocated for each table in the table-space.
Optional setting for optimizing the cache size used for storing query predicates against a table in this table-space. The size is allocated for each table in the table-space.
Embedded publisher applications can be placed in a sub-folder of the main project root; if so, this attribute specifies the folder name. Make sure this folder is on the project's module search path.
A jdbc-table is a table that executes queries against data stored in a remote SQL database via JDBC. A reference to a data source defined in sbd.sbconf is required.
SQL statement (that must return a result set) that LiveView queries will execute against. LiveView queries are executed against the result of this statement as a sub-query. Wrapping this with the CDATA tag is recommended.
Optionally define the fields of this table. When specified, field names and types that match the result set from the sql statement must be compatible; fields that do not match by name will always return null. Additionally, defining fields here will skip type checking the SQL statement on startup.
Defines the maximum number of snapshot queries (one per thread) within a partition that are executed at once. This attribute overrides the same attribute defined in the table's tablespace.
Defines the number of table partitions, and the number parallel regions used to scan a table during the snapshot portion of a query. This attribute overrides the same attribute defined in the table's tablespace.
Definition of a field including type and optional insert or update rules. A field that is designated as a primary key cannot have insert or update rules.
Path to the sbapp or sbint file from which to import the schema. The path is relative to the project root (where the top-level lvconf must reside). If you specify a simple file name, LiveView searches for the file on the current project's module search path.
Embedded publisher applications can be placed in a sub-folder of the main project root; if so, this attribute specifies the folder name. Make sure this folder is on the project's module search path.
Path to the sbapp or sbint file from which to import the schema. The path is relative to the project root (where the top-level lvconf must reside). If you specify a simple file name, LiveView searches for the file on the current project's module search path.
There are certain unusual situations where a start-up artifact from a preprocessing app is not available early in LiveView server start-up. In these rare cases, in order to allow LiveView to run, you can skip typechecking of the referenced preprocessing app by setting this attribute to false. The downside is that you will no longer receive compile-time typecheck warnings, and may get runtime exceptions if your configuration is wrong.
A table join can be half-active or full active. For a half-active join of two tables, a local table and a foreign table, when a row in the local table is inserted or updated, a lookup of a row in the foreign table is performed based on the join keys, and the lookup results update the data in the local row. A full-active join performs an update of the local table when either the local or the foreign table is updated.
A valid output stream of the application to receive data from.
Application streams that are intended to send data to LiveView or receive data from LiveView must be marked public; that is, the stream property "Always expose Stream for Dequeue" or "Always expose Stream for Enqueue" must be set.
When a table is configured with snapshot-parallelism, setting this attribute to true pushes the processing of this aggregation into the same parallel region as snapshot processing. In general, performance should be better by running inside the parallel region. If a particular aggregate function specified in the configuration cannot be run in parallel, this setting is ignored.
There are certain unusual situations where a start-up artifact from a preprocessing app is not available early in LiveView server start-up. In these rare cases, in order to allow LiveView to run, you can skip typechecking of the referenced preprocessing app by setting this attribute to false. The downside is that you will no longer receive compile-time typecheck warnings, and may get runtime exceptions if your configuration is wrong. If typechecking is enabled, the system attempts to coerce fields to be the correct type, such as converting an integer to a long, or filling in empty fields with null.
When a table is configured with snapshot-parallelism, setting this attribute to true pushes the processing of this transform into the same parallel region as snapshot processing. In general, performance should be better by running inside the parallel region.
Under normal circumstances, cycles in the configuration graph are not allowed. Under certain advanced cases it might be necessary to have a cycle in the graph. A simple example would be table A publishing to table B and table B publishing back to table A. If a scenario like this is required, a custom transform should be introduced and the “allow-cycle” attribute should be set to true. This setting should be made with great care.
Defines the number of table partitions, and the number parallel regions used to scan a table during the snapshot portion of a query. This attribute overrides the same attribute defined in the table's tablespace.
Defines the maximum number of snapshot queries (one per thread) within a partition that are executed at once. This attribute overrides the same attribute defined in the table's tablespace.
This setting applies to all table types, and is used to specify in milliseconds the amount of delay before publishing data from the table; this condition is known as conflation of data. Set this attribute to a positive, non-zero integer ≥ 5 to specify conflation for this table. A value below 5, including zero and all negative numbers, is forced equal to 5. Static aggregation tables have an internal setting that is the equivalent of setting publish-interval-millis=1000 (1 second). For such tables, you cannot disable conflation, but you can change the conflation interval by setting publish-interval-millis to a different integer value. For all other table types, specify a value for publish-interval-millis to both enable conflation and to specify the conflation interval. To disable conflation for non-aggregation tables, remove the publish-interval-millis attribute entirely from your table’s lvconf entry.
Without conflation, data is published from a table as soon as it is received. With conflation enabled, all downstream components see conflated data, including alerts, LiveView Desktop, clients built with the Java or .NET APIs, or another table in a transformation sequence. If an alert is set for a conflated table, be aware that it is possible for conditions that would otherwise trigger an alert to occur briefly during a conflation period; in this case, the trigger conditions are conflated away and the alert does not trigger. See the Data Conflation topic in the LiveView Reference Guide for further information.
An application cam be placed in a sub-folder of the main project root; if so, this attribute specifies the folder name. Make sure this folder is on the project's module search path.
Optional default value for this parameter. Since parameters are fulfilled in order, if one parameter is unspecified (using the default), then all parameters after it must also be left unspecified.
Optional setting for optimizing the cache size used for storing query predicates against a table in this table-space. The size is allocated for each table in the table-space.
Optional setting for optimizing the cache size used for storing query predicates against a table in this table-space. The size is allocated for each table in the table-space.
Embedded publisher applications can be placed in a sub-folder of the main project root; if so, this attribute specifies the folder name. Make sure this folder is on the project's module search path.
