LogicBlox 4.18.0

Release Date: November 12, 2019

What's New

LogicBlox 4.18.0 introduces the following enhancements:

  • Modeler IDE
    • The presentation of error messages in the Validation Console has been improved.

    • Users can now remove a default aggregation and spread method set at the Measure Component level by adding an override with the option "None" at the Measure Variant level.

    • Actions can now be configured to be initially disabled by checking the "Is Disabled?" option.

    • Validation and the presentation of error messages have been unified throughout the Modeler IDE.

  • Tools, Database, and Services
    • All Python scripts in the LogicBlox distribution have been upgraded to Python 3. Starting from this 4.18.0 release, LogicBlox no longer supports Python 2.7 which is nearing its End Of Life (EOL) at the end of 2019. For more information, see the Upgrade Information section.

    • Added a user registration service to lb-web. This service can be used to manage users and password policies. See the LogicBlox Administration Guide for more detail.

    • Revisited a previously existing cases construct in LogiQL, improving its performance and fixing many known problems that made it unusable in the past. The cases construct provides something similar to switch-case statements used in other languages. Using cases can make writing some LogiQL patterns easier and more concise.

      As an example, consider a sales application where the price of an item might be reduced by a fixed amount (fixed_off below), or by a percentage (percent_off below), or left unaltered (default_price below).

      new_price[x]=newPrice <-
         Item(x), default_price[x]=p
         cases x, p => newPrice
         of fixed_off[x]=z1 => newPrice = p - z1
         else percent_off[x]=z2 => newPrice = p * (100f - z2) / 100f
         else newPrice = p.

      A case statement contains a list of case variables (here x and p), result variables (here newPrice), and a sequence of branches (three of them in this example). Each branch consists of a guard followed by a consequence. The guards are considered in order (using the case variables as "input") and for the first guard that is satisfied the consequence is used to determine values for the result variables. A branch can also have local existential variables (here z1 and z2).

    • Added a lang:fullEval LogiQL property that can be used to mark predicates that you don't want to be incrementally maintained. This will prevent sensitivity indices from being created and maintained for the predicate, which in some rare cases can improve performance.

  • Measure service
    • The protocol definitions in measure_common.proto have been merged back into measure_protocol.proto as there is no longer any reason to keep them separate.

    • Introduced the asynchronous measure service. This is a new handler implementation named measure-async that offers a websocket interface to the measure service via new AsyncRequest and AsyncResponse messages. Interacting with the measure service via a persistent websocket session offers many advantages and possibilities that are unavailable with the old synchronous measure service implementation.

      The first new feature we are exposing in the new asynchronous service is the ability to request watches on installable CubiQL expressions. Separate notification messages will be asynchronously sent to the client whenever watched expressions change. The changes do not need to originate from measure service edits. For example, notifications will also be sent if a change is caused by modifying LogiQL EDB predicates, caused by adding new LogiQL rules, or caused by TDX imports. Watches will be maintained until they are explicitly cleared by the client or the session is closed.

      Because closing the connection between client and service will now clear outstanding watches, which may be undesirable, it is no longer advisable to abort requests by closing the connection. A new AbortRequest message has been added to allow cancellation of unfinished requests.

      As the service is truly asynchronous, it is possible that the client will receive the responses to its requests out of order depending on the nature of a request. AsyncRequest messages are now required to include a sequence number to allow matching with AsyncReponse messages. AsynResponses not directly corresponding to a specific request will instead include a timestamp field.

Corrected Issues

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

  • Modeler
    • The Spanish translation contained an untranslated validation message, this translation had been added to the language file provided by Modeler.

    • Dropdown options are now properly rendered in the Conditional Formatting panel.

    • Fixed an issue with word wrap in Modeler's info, warning, and error alerts.

  • Modeler IDE
    • Fixed an issue where the "+ New" button for adding Measure Variants would be grayed out after deleting existing Measure Variants.

    • Eliminated circular references between variants and measures in the project configuration files. This resolves an error which could occur after deleting either Measures or Measure Variants.

    • Fixed an issue where measure components could no longer be added after deleting a measure component.

    • The Modeler IDE no longer reports a problem when the user enters "$" for the Currency Symbol when adding a Format override.

    • When the "There is an error in the application" screen is presented, the user was not able to open a different project. This has been fixed.

    • The Modeler IDE now presents a proper error message when a level exists and is not in at least one hierarchy.

    • The Modeler IDE no longer shows measures which have been deleted. Before this fix, deleted measure names were shown when selecting an inverse's update measure, in the CubiQL editor auto-completion feature, and when selecting a measure in the Spread by Metric dropdown.

    • Users were not able to correct the validation errors related to measures still referring to deleted Measure Components and/or Measure Component instances. This has been fixed.

    • Instead of trying to create an empty project, the Modeler IDE will now show a message to the user when the folder for the last open project no longer exists.

    • The Validation Console is now scrollable.

    • The Modeler IDE no longer presents a confirmation dialog when there are errors on one tab of the measure variants and the user switches to another tab. The confirmation dialog is still presented when there are errors and the user switches to a different measure.

    • Fixed an issue where the Value Type could show up as undefined in the "Default Values" section of the "Overrides" tab of a Measure Variant.

    • The "Enable HTML" option in the Actions view is no longer grouped the unrelated "Has Confirmation?" field.

  • Tools, Database, and Services
    • Added HTTPS support to lb-workflow. Previously, lb-workflow converted all HTTPS requests to HTTPS requests.

    • Fixed an intermittent failure that occurred in lb-web when processing SAML / SSO requests.

Known Issues

The issues listed below are known to exist in the 4.18.0 release.

  • Modeler IDE
    • The Modeler IDE application bundled with this release crashes on macOS systems.

  • Tools, Database, and Services
    • LogicBlox currently has issues running on Python 3.7 since it's not fully backward-compatible with Python 3.5. In some Python scripts bundled with this LogicBlox release, we have an argument called async which has become a reserved keyword in Python 3.7.

    • This release contains changes to some lb-workflow tasks related to workbook creation. These fixes have not been applied yet to lb.wb.CreateWorkbook, which means errors related to recent changes in the LB runtime that imposes restrictions on string lengths can still occur. Please note that this known issue does apply to lb.wb.util.CreateWorkbook.

Installation Information

Install LogicBlox 4.18.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.18.0).

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

  • Tools, Database, and Services
    • This LogicBlox release requires Python 3 to be the default python version. Users can determine the default python version on their system by running:

      python --version

      The 4.18.0 release has been tested thoroughly with Python 3.5. It is also likely to work with more recent Python 3 versions. If your system has Python 3.6, it is recommended to try using LogicBlox with that first, and only downgrading to 3.5 if any issues occur. For Python 3.7, there is a known issue that will be resolved in a future upgrade.

      If the default python system version is not Python 3, on Ubuntu systems it can be set via:

      $ sudo update-alternatives --config python

      and selecting a Python 3 version from the displayed options. If no Python 3 version is displayed, one needs to be installed via:

      $ sudo apt-get install python3

      On MacOS systems, one can use pyenv to set the default python version, and/or install a version of Python 3, if none is available:

      # Install pyenv, if it is not available already
      $ brew install pyenv
      # Install a version of Python 3, e.g., 3.5.2, if no Python 3 version is available
      $ pyenv install 3.5.2
      # Set python 3.5.2 as the default system python version
      $ pyenv global 3.5.2 

      pyenv can also be used on Ubuntu systems, where it can be installed as follows:

      $ sudo apt-get update
      $ sudo apt-get install -y build-essential libbz2-dev libssl-dev libreadline-dev libsqlite3-dev tk-dev
      $ curl -L https://raw.githubusercontent.com/pyenv/pyenv-installer/master/bin/pyenv-installer | bash 

      More information about how to use pyenv can be found here or here.

      In both MacOS and Ubuntu, users may need to add the following to their .bash_profile for MacOs/.bashrc for Ubuntu, in order for pyenv to work correctly:

      export PYENV_ROOT="$HOME/.pyenv"
      export PATH="$PYENV_ROOT/bin:$PATH"
      eval “$(pyenv init -)”
      eval “$(pyenv virtualenv-init -)” 

    • Application projects that are built using nix will likely need to replace references to pkgs.python in the build inputs of their default.nix with pkgs.python35.

      While migrating some platform components to work with the py3 version of LB, we noticed that some build or testing targets in their config.py only work correctly if executed in a particular order. In some such cases, builds that used to work with the py2 version of lb config (or may have been failing intermittently) may not work with the py3 version of lb config. The correct solution for such cases is for the config.py to include explicit rules describing such dependencies when they exist (e.g., if a step A needs to run before a step B, there needs to exist a rule with B as the output and A among its inputs).

      Application projects that have their own python scripts will need to migrate them to work with Python 3. In most cases, this can be done automatically using the 2to3 tool, e.g., via commands such as:

       $ 2to3 -f all -w test.py 

      More instructions about how to use this tool can be found here. More information about porting Python 2 code to Python 3 can be found here and in the Infor Wiki (only accessible through the Infor VPN).

    • Python3 requires that all sections in config files have a header. Any config files (e.g., lb-server.config or lb-web-server.config) that have any lines in the beginning that are not preceded by a header, will need to have the header [global] added before those lines.

    • Users building the platform locally from source will need to get a new lb-deps-complete.tar.gz file from this jobset.

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 3.5
  • 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.