LogicBlox 4.4

LogicBlox 4.4.16

Release Date: June 19, 2018

What's New

LogicBlox 4.4.16 introduces the following enhancements:


    • Modeler startup time has been improved significantly by loading resources such as the navigation tree, views, and the measure model in parallel.

    • Modeler now supports a new tile-based layout for canvases. It aims to maximize the available space by subdividing the canvas into resizable tiles. Unlike the current grid-based layout, the tile layout is designed to fit as much data on the screen as possible and to be easily resizable.

      Tiles can be altered through the user interface. To resize a tile, click on the border between panes and drag to increase or decrease its size:

      To enable and configure the new tile-based layout you should specify a tileLayout property within the canvas configuration JSON file. It has a tree-like structure. For example, the view above has the following tileLayout in its canvas configuration:

      Example 1. 

      "tileLayout": {
        "direction": "column",
        "panes": [
            "id": "three-sheet-top-sheet"
            "minSize": "40px",
            "direction": "row",
            "panes" : [
                "id": "three-sheet-bottomL-sheet",
                "minSize": "40px"     
                "id": "three-sheet-bottomR-sheet"
                "minSize": "40px"

      First of all, you should specify the direction property to set the orientation (column or row) for the panes and panes to define the children of the container. Tile-based layout supports multiple panes per container and each pane may be a container for others. You can specify the size of pane by pixels, percentage or ratio units as well as set min/max size (percent and pixel are supported). The id property points to the view (which described in views section of the canvas JSON) that should be rendered for that pane. If you don't specify the id the pane will be rendered without any content.

      The old grid-based layout will continue to exist but will be deprecated in future releases. For now, when both layout and tileLayout configs are specified the tileLayout will be used. In this case Modeler will print a warning message in the browser's Javascript console.

    • Because of potentially confusing results, the ability for the user to specify E, P, and D spread suffixes has been disabled when entering new data (e.g. 20000E) into cells that contain formula defined measures. The behavior of the R suffix has been changed. This suffix now replicates the value to the base intersection for formula defined measures.

    • Modeler will now ignore custom view components when validating canvases and view configurations provided that the module attribute begins with the word Custom (case-sensitive). This only applies to applications that contain custom views defined in Javascript.

    • Modeler's testing library ModelerTestUtil is now aware of the amount of data that can be displayed at once. The function $queryForSheet and all the functions that depend on it (such as queryCanvasById, $queryCSV, $queryExcel, etc.) in ModelerTestUtil will check level sizes before loading level members and cells.

      If any level is oversized it will throw an error of the following shape:

          message: "Levels Foo, Bar are overised.",
          countData: { ... } // an object having all levels sizes.

      The $queryForSheet function signature is:

       * Given a sheet configuration, it will issue all required
       * queries for that sheet. Similar to how the modeler works in the browser,
       * this will only query level members if they have not been queried previously.
       * @param {Object} sheetConfig - a sheet's JSON configuration, as you would store in the workspace
       * @param {MultiAxisRange} [range] - an optional parameter that says what the range of the view is, defaults to {X: { start: 0, length: 50}, Y: { start: 0, length: 20 }}
       * @param {Boolean} [failOnError] - if this should fail on any query error. Defaults to true
       * @param {Boolean} [checkLevelsSize] an optional parameter that says whether the data should be loaded only if the levels sizes are not oversized, defaults to true.
       * @returns {Promise} - a promise that is resolved when the queries are complete
      $queryForSheet(sheetConfig, range, failOnError, checkLevelsSize = true) {

      Thus, in tests if you want to check whether any level is oversized you can do the following:

          .catch(err => {
              // Where the err argument is an object of aforementioned shape.


    • When importing protobuf descriptors into a workspace, the package of the descriptor can be mapped to an alternate namespace in the destination workspace. This allows developers to create multiple sets of predicates representing the protobuf in the same workspace without manually copying and renaming protocol packages, which is useful in some cases where some of the storage characteristics of the protobuf predicates need to be altered (a transaction lifetime version and a database lifetime version for example).

      The namespace mapping can be done when using the protoAddSpec dlbatch command or from within LogicBlox compiler project files. A dlbatch example is:

      protoAddSpec --name MyProtocolName --file my-protocol.descriptor --map "original:package->new:target:namespace"

      In a compiler project file, the equivalent example would be something like:

      my-protocol.proto, proto, descName=MyProtocolName legacyLogic=true namespace={original:package->new:target:namespace} lifetime=database

    • A new kind of model to evaluate SFAMA (Stratisfied FActorization MAchines) models has been added to the predict p2p. lwfm can train those models. See the lwfm documentation (version 1.9.13) for details.


    • Added static conditionals to CubiQL. This can be used to execute different queries depending on the relationship of intersections.

Corrected Issues

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


    • When editing dropdown cells for entity typed values with more than one key, Modeler will now display the actual Label instead of the ID.

    • When a user right-clicks on a header in the grid to lock a position, the context-menu used to display the ID of the position. Since the user might not recognize this value, Modeler now displays the Label instead, which will match the value the user clicked on.

    • Views in Modeler no longer become unusable when opening the conditional formatting panel with no measures on the grid.


    • Improved performance of the runtime in cases where wide fixed-length values are used in predicates. The performance issue was most noticeable in use cases that follow an append-to-back and delete-from-front modification pattern.

    • Improved performance of rule maintenance for rules that use inverse constructors of one-to-one predicates. These rules are now qualified for prefix-join and no sensitivity indices are needed.

    • The script P2P will now always use flat iterators instead of directly operating on alpha-trees, resulting in potentially significant performance improvements.

    • Fixed an error in the runtime where intermittent crashes would happen with MacOS High Sierra involving 128-bit integers.


    • Improved handling of recursive metric definitions in CubiQL.

    • Fixed an issue with the interaction between the ambig aggregation method and slides.

    • Fixed an issue with rewinding aggregations containing slides. This has also been backported to the 4.4.15 release.

    • Fixed an issue with the predicate binding for CubiQL feature, allowing the key order of the bound predicate to differ from what the measure service would itself choose. However, note that if it does differ there will be a performance penalty to create and maintain an index.

    • Improved CubiQL error reporting for cases when there is a mismatch in default values between metric definitions and what is expected by the rule execution engine. Also improved propagation of errors from the server back to the CubiQL REPL interface.

Upgrade Information


    • Modeler no longer supports historical locks using the pivot config's pivot:config:lock:lock predicate. Any historical locks that were applied by populating the pivot:config:lock:lock predicate will no longer be valid and any logic using this predicate will fail to compile as the predicate no longer exists.

      Historical locks should be installed using the installed target lock functionality. To see how historical locks can now be configured, see this section in the LogicBlox 4.4.14 release notes.

    • Modeler now expects navigation trees, sheets, and canvases to be grouped by their respective applications (workbook templates). This allows Modeler to only query out the views needed for a specific application.

      Navigation trees, sheets and canvases will now be organized according to their application in the src/config/views directory where each application has its own subdirectory src/config/views/<application>. Each application directory should contain a navigation.json file that contains the navigation tree for the application. The nav tree id is expected to match the containing application folder name (see below). Any canvas referenced in the navigation file should be placed in the corresponding folder under src/config/views/<application>/canvas. Likewise, any sheets referenced in the navigation file or referenced by a canvas included in the navigation file should be placed in the corresponding folder under src/config/views/<application>/sheets.

      Example 2. 

      Old Structure:

      * src/config
          * navigation/
              * main.json
              * partition_by_class.json
          * canvas/
              * canvas1.json
              * canvas2.json
          * sheets/
              * sheet1.json
              * sheet2.json
              * sheet3.json
              * sheet4.json

      New Structure:

      * src/config/views/
          * main/
              * navigation.json
              * canvas/
                  * canvas1.json
                  * canvas2.json
              * sheets/
                  * sheet1.json
                  * sheet2.json
                  * sheet3.json
                  * sheet4.json
          * partition_by_class/
              * navigation.json
              * canvas/
                  * canvas2.json
              * sheets/
                  * sheet2.json
                  * sheet3.json

      All view and viewstate predicates (e.g. modeler_platform:views:model:user_viewstate) now include a new string primitive key that represents the application associated with the view or viewstate. Processes that import/export this data may need to be adjusted for this change. We have also updated the protobuf message for deleting viewstates to use the below schema:

      message ViewStateDeleteRequest {
        required string userName = 1;
        required string viewId = 2;
        required string application = 3;

      As we now store views by application and only retrieve the views required for the current application, Applications and their test suites need to be updated in order identify the correct application for which the views should be queried.

      The Modeler migration tool contains a script to upgrade existing projects to the new sheet/canvas folder structure. The migration script will be run when upgrading to version 4.4.16 or by applying the storeViewsByApplication transform directly to your project.

      For ModelerTestUtil, this is accomplished by adding the appId parameter to ModelerAppConfig object that is passed into the ModelerTestUtil object when initialized. A sample configuration is provided below.

      const modelerAppConfig = {
          appId = "tree_id",
              appPrefix: "/internal" + app_prefix,
              workbookUrl: "/internal" + app_prefix + "/workbooks"
          levelMembersQuantityThreshold: 10000
      new ModelerTestUtil(modelerAppConfig, "test-branch");

    • The library containing the Modeler migration tool is included in the distribution under 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 path/to/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.

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

Installation Information

Installation Instructions

Install LogicBlox 4.4.16 by following the steps outlined below:

  1. Download the installation package.
  2. Extract the tarball in <YourPreferredInstallDirectory>
  3. Run the following command:
    source <YourPreferredInstallDirectory>/logicblox-4.4.16/etc/profile.d/logicblox.sh
    NOTE: this script will set all the necessary environment variables. You might want to add this command to your .bashrc.

Release Information

Server requirements
Operating System: 64 bit Linux; macOS 10.10+ is supported for local development.
Java Runtime Environment 8
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.