LogicBlox 4.8.0

Release Date: November 12, 2018

What's New

LogicBlox 4.8.0 introduces the following enhancements:

  • Modeler
    • Users can now resize the side panels of a sheet in Modeler.

      Example 1. 

      This new feature makes it easier for users to identify measures with long names in panels such as the configuration panel.

    • Modeler now supports the configuration of data access permissions for Modeler workbooks.

      Before this release, users always had WRITE access to data available within an accessible workspace. Therefore, it is a common practice to restrict user's WRITE permissions by giving users access to workbooks that contain limited amounts of data. This solution often results in a large number of smaller workbooks being built to accommodate the permissions needed for an application. In this release, user permissions can be configured such that users of an application can have different READ permissions for specific hierarchy positions within each workbook template. This allows workbooks to be built that contain data for multiple users with different data access permissions. Please note that READ permissions are not indicated in Modeler's UI at this time.

      Schemas - Users have WRITE permissions by default. The permissions schema and ruleset for configuring READ access permissions can be installed by adding the permissions project to your build. This project provides the following predicates that need to be populated in order to have permissions applied for a template:

      permissions:permissions_schema:user_permissions is the base predicate that must be populated for permissions to be applied.

      user_permissions[user, template, dimension, level, memberId, applyAll]= perm ->
          string(user), // lb:web:auth:username
          string(template), // lb:web:workbooks:interface:template_name
          string(memberId), // Set to an empty string if applyAll == true, else should be level ID
          permission(perm), // Currently only READ is supported. WRITE is the default
          boolean(applyAll). // If true, we will apply security all members for this level

      permissions:permissions_schema:up_on_some is the predicate that determines how security rolls up to a parent when its children are partially locked. By default, the parent is locked if all children are locked. If set to true, locking a single child locks the parent.

      up_on_some[template, dimension, level] = up_on_some ->
          string(template), // should match the template_name predicate

      Hierarchy Permission Traversal

      The measure service will handle pushing permissions up or down the hierarchy based on the up-on-some method and the configured parent-child relationships. For determining permission at lower levels in the hierarchy, setting READ access to any parent level causes all children of that parent to be assigned READ access. When determining parent security, the measure service applies security based on the configured up-on-some method. If false, then parent levels are locked only if all children are locked. If true, locking a single child locks the parent.

      When multiple dimensions are locked, a measure will be read-only if any locked level in the key space has READ access.


      • User has READ access to sku-1 and store-1
      • Sales has an intersection of [sku, store]
      • These intersections are read-only:
        • sku-1, store-1
        • sku-1, store-99
        • sku-55, store-1

      Services - Services have been provided to allow developers to update/retrieve the workspace permissions.

      /user_permissions can be used to upload data into the user_permissions predicate. The upload file is expected to have the following format USER,TEMPLATE,DIMENSION,LEVEL,MEMBERID,APPLYALL,PERMISSION. The current permissions can be retrieved from /user_permissions.

      Example 2. 

      The following sample provides permissions specifications for two users. The first two lines set subclass-1 and store-1 to READ for user4 in the workbooks using the partition_by_classweek template name. The third line sets all Product:subclass level members to READ for user4 for the partition_by_class template.


      /dimension_lock_up_method can be used to upload data into the up_on_some predicate. The upload file is expected to have the following format TEMPLATE,DIMENSION,LEVEL,UPONSOME. The current permissions can be retrieved from /dimension_lock_up_method_file.

      Example 3. 

      The following sample import sets up_on_some to true for permissions applied to Product:subclass withing the partition_by_classweek template for all users that have access to workbooks of that type.


      Measure Model Restrictions - In order to support user permissions, we make use of four internal metrics in the measure model. UserPermissions, UpOnSome, CurrentUser, CurrentTemplate, UserLockedIds, and UserLockedAll are now reserved measure names and are hidden from the users in the Modeler application.

      Master Workspace Permissions - By default, the permissions rules are not installed until the predicate lb:web:workbooks:interface:template_name is set in a workspace. This means that the master workspace will not, by default, have permissions applied. If you need to have permissions in the master, ensure you set this predicate in your build after the project is installed and permission data is loaded. You can disable permissions by retracting the value from lb:web:workbooks:interface:template_name. Also note that the template name you use for the master workspace must also be used when populating the permissions:permissions_schema:user_permissions and permissions:permissions_schema:up_on_some predicates.

      Measure Model Updates After Build - Adding and removing users from permissions:permissions_schema:user_permissions can be done on the fly without restarting the measure service. However, adding or deleting templates, qualified levels, or the up-on-some method for a qualified level requires the measure service to be restarted. The current model expects that updated permissions will be loaded into the master workspace and then be pulled into child workspaces using the refresh action. In order to accomplish this, you will need to add UserPermissions and UpOnSome to your workbook refresh rules.

  • Tools and Services
    • The signature algorithm used by the lb-web SAML implementation is now configurable through the signature_algo option in lb-web-server.config. Supported values are sha1, sha256, and sha512. The default is sha512.

    • The inherited property in the [tcp:public] and [tcp:private] sections of lb-web-server.config is no longer needed. This was previously used to indicate that lb-web-server ports would be allocated by and inherited from systemd. Another mechanism is now used to detect when services are started within systemd and the inherited property is no longer used. All ports are now inherited if lb-web-server was started by systemd.

    • A new access_log_journald lb-web-server configuration option has been added. Setting this to true will post the lb-web access logs to the same journald service used by lb-web-server. The default value is false which will cause access logs to be stored in a separate $LB_DEPLOYMENT_HOME/current/lb-web-server-access-*.log file.

    • Improved memory management for protobuf services, which can lead to up to 65% less memory required in some conditions.

  • Measure service
    • Improved the error message produced when an inverse computes data at a different intersection than its target metric.

    • The CubiQL grammar has been restructured so that it should be possible to write many CubiQL expressions with fewer parentheses.

Corrected Issues

The issues listed below have been corrected since the 4.7.0 release:

  • Modeler
    • The validation error message in the Country field for address-typed measures now contains a valid translation.

  • Tools and Services
    • The lb.CreateZipArchive workflow task can now be applied recursively on both local filesystem and remote storage service paths. This behavior is optional and controlled by the newly added --recursive parameter. By default, the command will operation non-recursively. This is a backward incompatible change that may require adjustment of existing workflows that use this task, but was required due to fixes in recent releases to incorrect path handling.

    • The lb.CopyFiles workflow task was fixed to treat new cloud-store path semantics correctly.

    • The lb.ListFiles workflow task was fixed to respect the --recursive option for both local filesystem and remote storage service paths.

    • Corrected a bug in the runtime that could produce out of bounds access errors during incremental maintenance of rules containing negated atoms with more keys than the global key order for the rule.

    • In the past, there has always been a limit on the length of string values in a predicate, imposed by the size of the pages our database uses. With this release, we are introducing a more rigorous limit on string length to ensure that we avoid pathological behavior and odd, hard to diagnose bugs in the database.

      The new restriction is aimed at ensuring that we can always fit at least a minimum of four tuples per database page. The rough formula for determining the maximum length of a string that can be inserted into a predicate is

      Max length = (Page size - Page metadata) / (4 * Num of string fields per tuple)

      Our current database page size is 32K. The size of the page metadata varies based on internal storage characteristics of a particular paredicate.

      Concretely, for a database lifetime predicate with declaration like Label[sk,st,wk]=v -> sku(sk), store(st), week(wk), string(v). the maximum string length in this release is 7570 bytes. For a database lifetime predicate with a declaration like pair(s1, s2) -> string(s1), string(s2). the maximum string lengths is 3781 bytes.

      Note that the maximum lengths may change in future releases. If we need to add new fields to our internal data structures, they could be reduced by a few characters. On the other hand, if we decide to switch to much larger database pages in a future release, the lengths could become several times larger.

  • Measure service
    • Fixed an issue where the CubiQL parser would ignore in-scope variables in favor of metrics. For example, if you previously had a metric called Sales and had the function fun (Sales) in Sales, we would parse the body of the function as a metric rather than a variable. Now it will correctly parse it as the variable bound by the function.

Installation Information

Install LogicBlox 4.8.0 by following the steps outlined below:

  1. Download the LogicBlox installation package for Linux or macOS from the LogicBlox developer website.
  2. Extract the tarball into a directory, which we refer to as <LOGICBLOX_HOME>.
  3. Run the following commands:
    source <LOGICBLOX_HOME>/etc/profile.d/logicblox.sh
    source <LOGICBLOX_HOME>/etc/bash_completion.d/logicblox.sh
    NOTE: these scripts automatically set all the necessary environment variables (please be aware that this script only works if you use bash as your shell). You might want to add these commands to your .bashrc.

Upgrade Information

  • Modeler
    • The library containing the Modeler migration tool is included in the distribution under <LOGICBLOX_HOME>/lib/npm/modeler-migrations-<VERSION>.tgz and contains a command line tool for doing various transformations/migrations of modeler configurations.

      To use the npm module, you first need to install it by running npm install <LOGICBLOX_HOME>/lib/npm/modeler-migrations-<VERSION>.tgz. You will then be able to use the command line tool. The module contains a README.md file that lists all available transformations as well as detailed instructions for use.

      To automatically upgrade a Modeler application from one version to another, run the upgrade script to upgrade between versions:

      ./node_modules/.bin/migrate-modeler --fromVersion <prevVer> --toVersion <toVer> /path/to/my/modelerapp

      where the version numbers refer to LogicBlox releases (e.g. 4.8.0).

      NOTE: If you installed the npm module globally, you won't need the ./node_modules/.bin prefix on the command.

Release Information

  • Server requirements
    • Operating System: 64-bit Linux; Apple macOS 10.10+ is supported for local development
    • Java Runtime Environment 8, update 101 or higher
    • Python 2.7 or higher
  • Client requirements
    • Applications using LogicBlox Modeler: Modeler supports major browsers not older than 1 year. Google Chrome provides the best performance.
    • Requirements for applications using non-LogicBlox Modeler components may vary per application.