LogicBlox 4.3.4

What's New

predicate@branch support:
LogicBlox now supports referring to a predicate on another branch
in ad-hoc queries and inactive blocks.
This feature makes database branches even more useful.

Predicates from other branches can be referenced in rule bodies via a
predicate@branchname syntax, similar to the syntax
for stage-names.

Example 46.

For example, if foo is a branch name, then

+R[x]=y <- S@foo[x]=z, T@foo[z]=y.

joins the versions of S and T
on branch foo, and inserts the result into the local version of R.

An arbitrary number of branches can be used for read-only purposes in a single transaction,
but only predicates on the local branch of the transaction can be written to.

Note

Use of this feature is limited to ad-hoc queries logic and inactive blocks.
In the current version, there are also some restrictions on the use of entities: in the example above, if e.g.

R[x]=y -> E(x), decimal(x),

where E is an entity type, then we need to add a "guard" to the rule:

+R[x]=y <- S@foo[x]=z, T@foo[z]=y, E(x).

This ensures that only entities existing both on the main branch and on
foo are copied over.

Some useful applications of this feature include:

Migration of data to a new version of an application:
The rules and schema of the new version are installed
in a separate workspace branch, and then rules using
predicate@branchname migrate the data.

Long-running write transactions, involving e.g. calls to a solver:
To avoid blocking write-transactions on the main branch,
these transactions can be done in a separate branch,
and then predicate@branchname
rules can be used to import the results.

Comparison of current and past database versions: Branches can be used to
"snapshot" the workspace at periodic intervals, and then
predicate@branchname
rules can be used to compare the versions.

Measure Service

Support for updating targets other than metrics. It is now possible to also edit

Attributes

Level members

Mappings between level members

+/add can now be used for string concatenation.

Ratio and even spreading on integer types will now spread exactly.
Previously there would be some loss due to naive division.

Editability: When in deferred calc mode, the grid will now
render cells that are no longer editable as read-only, based on a user’s
outstanding edits. Editability is computed at the granularity of intersections,
(e.g. (Sku, Store, Day)) rather than positions (e.g. (sku-1, store-3, day-2)).
This level of granularity can be too coarse; improving it is part of future work.

Example 47.

Figures 1 and 2 show a simple sheet with 3 measures: Sales, Returns
and NetSales at their base intersection (SKU,Store,Day). The measure
NetSales is defined via the following primary and inverse rules:

In the initial situation as depicted in Figure 1, all 3 measures are editable.

Figure 2 shows that once the user switches to deferred calc mode and updates Sales(sku1,store1,day1)
as well as NetSales(sku11,store1,day1), Returns is
not editable anymore at any intersection.

Dynamic drop-downs: Drop-down selections can now
be configured and filtered through a measure. Based on the content of the measure,
the selection in the drop-down can change.

Example 48.

This feature is particularly useful for showing attributes of products, where only certain attributes are relevant for
a given product, but not another. For instance, a dynamic drop-down can be used to show
only brands relevant for the product class on the same row.

Formatted input: Grid cells now accept formatted inputs.

Example 49.

For example, letters, such a M for "million" or B for "billion" can be used to enter large numbers
quickly. The supported formatted inputs are listed below.

User entry

Considered as

.25

0.25

2,000

2000

$2000

2000

2%

0.02

2k

2000

2.02k

2020

2M

2000000

2B

2000000000

2T

2000000000000

Input validation: Cell inputs are now validated against the
accepted cell type.

Example 50.

For instance, entering a non-numeric value into a numeric cell will result in an error presented
to the user, asking her to correct her input.

Precise integer spreading: Integer spreading requires
special handling when the value being spread result in a remainder after integer
division evenly or by ratio across all elements at the intersection.
Spreading the number 6 evenly across 4 elements is such an example.
Precise integer spreading, the default spreading method now used with
integer-valued measures, spread the remainder after division across some
randomly selected number of elements as evenly as possible,
such that the aggregation after the spread is the same as the value being spread.

Export CSV feature now exports data formatted as they are displayed in the grid:
for instance, numbers are formatted with currency signs if applicable, entities are formatted using their labels.

Configuration of displayableMeasures per sheet:
displayableMeasures can now be configured at the sheet level, instead of the canvas level.
Previously configured displayableMeasures at the canvas level will continue to work,
being applied to all sheets in a canvas. This new feature allows users to configure the available
measures in the Model Browser per sheet, which can be useful when configuring canvases with multiple sheets.

Users can now configure the direction that the cursor should move upon pressing the TAB key.
This can be achieved via the "Pivot Settings" window that is available via the cogwheel on the lower-right of the grid.

Developer Tools

The option suppress_task_parallelism is now supported in
lb-server.config.
It used to be only supported as an environment variable.

Note

This option is only useful for performance analysis and should not be used for other purposes.

Corrected Issues

The issues listed below have been corrected since the 4.3.3 release.

Replication:

On the primary database, the command lb info
now lists the IP addresses and ports of the active mirrors.

Resolved an issue that was causing the primary and secondary database to grow very quickly in size.

Resolved an issue where the secondary database would return query results for the
latest database version if the primary database server was killed.

When executing a transaction on the secondary database we no longer require
all pages for later versions of the database to exist in the primary database. This
is particularly important when the secondary database
is used for very long-running transactions.

Improved robustness of UUID checks that prevent a secondary database to
receive a mixture of pages from different instances of the primary database.
Importing a database into the lb-server now changes its UUID.

Default Value:

Resolved a semantic problem with default values in delta rules.
Delta rules with default values in the body are now also substantially
more efficient than the old implementation of default values in LB3.

Example 51.

For example, a delta rule that needs to replace the full content of a predicate f
with the content of g (^f[x,y,z] = v <- g[x,y,z] = v. )
now only considers the union of the non-default facts of predicates
f and g.

We now guarantee that EDB default value predicates never materialize facts
that have a default value. This means that it is not possible for a
database to become densely populated with default values over extended usage.
For IDB aggregations it is still possible that a default value is materialized
due to incremental re-computations of the value leading to the default value.

Optimized evaluation of equality comparison to constants for boolean-valued
default predicates (for example f[x] = true or f[x] = false).
When comparing the value for equality to the non-default value,
then the facts with default values are efficiently ignored.
Earlier developers had to convert the equality to an inequality.

Fixed a performance problem in checking for deltas in incremental maintenance of an IDB rule.
This check could be expensive in some specific cases where indexes were earlier created online.

Resolved an issue that was preventing blocks from being removed from the workspace in some situations.

Installation and Upgrade information

Installation Instructions

Installing LogicBlox 4.3.4 is as simple as following
the steps outlined below: