LogicBlox 4.4.5

Release Date: June 4th 2017

Executive Summary

LogicBlox 4.4.5 introduces the following enhancements:

  • The database now offers improvements to the datetime and string primitive types, such as support for microsecond precision and a set of operations for string values that are Unicode-encoding and locale aware.

  • Improvements to the Services Framework include custom-header support for the lb web-client API, support for multi-valued headers in HttpClientResponse, as well as login-based authentication for lb web-client.

  • The Measure Service now supports the int128 type, offers an exciting experimental feature for disabling the caching of logic by installation and some other improvements to help developers with debugging.

  • Developers of modeler-js based applications can now take full control over the forms that are presented to users when creating new level members. Additional measures can be added to the forms by writing logic; for more extensive customizations, a custom React component can be used.

What's New

Database

  • The datetime type now uses microsecond precision and datetime:now results in a datetime value with microsecond precision. At the protocol level, an additional field has been added for the microsecond value, so clients that use the existing field for seconds and ignore the field for microseconds will continue to use a precision of a second.

    Note

    This should be a backwards compatible change for typical applications, but the change is observable, for example applications could be relying on microseconds being formatted to 0.

  • The string type now supports various Unicode-aware operations. String values are treated as sequences of bytes, and LogicBlox supports Unicode by assuming a Unicode-encoding in UTF-8. String operations like string:length and comparisons simply use the byte sequences, which may or may not be the intention. LogicBlox now provides a second set of operations for string values that are Unicode-encoding and locale aware.

    Example 41. 

    For example, ustring:length returns the number of Unicode codepoints. The value of string:length["\u20AC"] is 3 (euro symbol as a UTF-8 byte sequence), while ustring:length["\u20AC"] is 1, which is the expected result if the number of Unicode codepoints is desired.

    Comparison operations now take a locale argument to perform the comparison, for example ustring:lt_3("sv", "mot", "måt") will perform the comparison in the Swedish locale. The new ustring operations are documented in the reference manual.

    Note

    Take a look at the reference manual for more detailed usage information and examples.

Language

  • The lang:oneToOne pragma may now be used with any functional predicate, and if necessary the appropriate constraint will be generated.

Services Framework

  • Added support for multi-valued headers in HttpClientResponse.

    Note

    A slight change in HttpClientResponse.getHeaders return type, from Map<String, String> to Map<String, List<String>> might break some users who use this method to read the response headers. In which case, one can simply get the first item in the list, if the header is known to have a single value, or use one of the new methods to get the header value directly. (see HttpClientResponse.getHeader(String name) and HttpClientResponse.getHeaders(String name).

  • The lb web-client Service API now supports custom headers.

  • LB web-client now supports login-based authentication.

Measure Service

  • The measure:config logic has been moved to its own library, as not all measure service projects need it.

    Note

    If your project is using this library, add the following line to your project file:

    lb_measure_service_config, library

  • The int128 type may now be used in definitions and int128 values can be queried.

    • The corresponding primitive Int128 dimension has been added.

    • int128 values are not currently supported in measure service literals, as there are no corresponding int128 literals in LogiQL.

  • QueryRequest messages now have a repeated field of MeasureExprs called constraint.

    • MeasureExprs added to this field will be checked at the after fixpoint stage to see if they are empty. If not, the transaction will be aborted. However, their contents will be returned as part of the Request message so that it is possible to report which values violated the constraints.

    • As a consequence, the Update.Target message's unique field has been deprecated (to be removed in release 4.4.7) as the same effect can be achieved using constraints, which will also report which levels already exist.

  • Experimental support for disabling the caching of logic by installation has been added. By setting the Request message’s install_logic field to false, the measure service will attempt satisfy the request without installing any logic. If this cannot be done, the request will fail with an error indicating the reason.

    Note

    Note that this feature is still experimental. If you encounter any problems let us know so we can move this feature closer to being viable for use in production.

  • The measure service will now pretty-print CubiQL expressions in a much more legible fashion and in syntax that can be parsed.

  • There is a new measure service lb command for converting expressions and requests between different formats.

    Example 42. 

    For example,

    lb convert --type expr --in-format json --out-format cubiql file.txt
    
    cat file.txt | lb convert --type request --in-format proto-text --out-format json 

  • The new configuration option called abbrev_code can be used to disable abbreviation of long names or constants in the logs.

  • The measure service will now return a 400 HTTP code unless the error is actually a server problem, in which case a 500 HTTP code will be returned.

  • The measure service will now add default value fields to Predicate messages for those predicates that have default values.

  • Optimizations to eliminate more empty literals from CubiQL expressions.

Modeler-js

  • Custom Level Member Creation Forms: The level member creation form is now fully customizable, reducing the development effort of teams for creating custom forms. Basic customization, such as adding additional measures or making measures required during creation, can be done using LogiQL. Additionally, we now provide a custom React component that gives developers full control over the data that is displayed to the end-users on the form as well as additional data that needs to get populated when the level member is created.

    Example 43. Level Member Creation with Measures

    The level member creation functionality has been updated to support measure value inputs for the new level members. When creating level members, users can specify values for the configured measures along with the level member creation. The measure values will be stored at the new level member position in the database.

    To configure the measures that should appear in the level member creation form, you will have to populate the following predicates in the database:

    • pivot:config:level_creation:metric: a string which is the name of an existing metric that has to be displayed on the form.

    • pivot:config:level_creation:is_required: to indicate that the metric is required for each new level member.

    • pivot:config:level_creation:is_hidden: to indicate that the metric should be hidden from the form.

    • pivot:config:level_creation:initial_value: initial value for the metric.

    • pivot:config:level_creation:is_read_only: to indicate that the metric should be displayed as read-only on the creation form.

    • pivot:config:level_creation:filterMeasure: can be used to filter dropdowns (entity-typed metrics).

    In the example below the measure SkuColor is added as a required measure with a default value of Black to the member creation form of the level Product:Sku:

    +pivot:config:level_creation:metric[l, 0] = m,
      +pivot:config:level_creation:is_required(l,m),
      +pivot:config:level_creation:initial_value[l,m] = "Black",
      +pivot:config:level_creation:filterMeasure[l,m] = "ColorMask"
          <-
          lb:web:measure:Metric_name[m] = "SkuColor",
          lb:web:measure:Dimension_name[d] = "Product",
          lb:web:measure:Dimension_level(d,l),
          lb:web:measure:Dimension:Level_name[l] = "Sku".

    Example 44. Advanced Level Member Creation Form Customization

    A custom React component can be used to customize the contents of the level member creation. The existing level member creation form is in logicblox.js as Views.CreateLevelMemberView which this custom component can use to render the level member creation form.

    The following props are available for the custom component:

    modelerApp: React.PropTypes.object,
            location: React.PropTypes.object, // Contains the context about where the component was invoked from.
                                              //  - location.state.prevPathname has the route from which the creation form was invoked
            params: React.PropTypes.object  // contains the level and dimension ids
                                            //  - params.dimensionName
                                            //  - params.levelName

    The measures that appear in the level member creation form can be customized as necessary. The customizations specified here will override the measures and the measures properties configured in the database.

    To do this, add the method transformJSON to the custom component. The method should accept the level creation config as its input argument and returns an updated level creation config. The level creation configuration is the configuration associated with the level for which a member is being created here. The metrics listed in the configuration will be displayed in the creation form. The configuration object is an array of objects where each object defines a metric and its properties. These metrics will be updated with the user entered values along with the level member creation after user clicks one of the two create buttons on the form.

    The following are the properties of the metric objects that will be in the array,

    • name: A string which is the name of an existing metric / ID / Label that should appear in the creation form

    • required: A boolean flag that indicates if a value has to be specified for this metric in the creation form. ID and Label are always expected to have a value.

    • readOnly: A boolean flag that indicates if this metric / ID / Label is a read-only or not.

    • initialValue: A string that contains the default value for the metric / ID / Label.

    • hidden: A boolean flag that indicates if the metric / ID / Label should be hidden in the form. This will be populated with value in value / initialValue property.

    • filterMeasure: A string that contains the measure name to be used for filtering the dropdown values of this measure. This is ignored for ID / Label.

    • value: A string that contains the current value for the metric / ID / Label.

    In addition to the metrics, the ID and/or Label can also be a part of this array. They can be customized in the same way as other metrics but the name property of these should always be ID for ID and Label for label.

  • Support for filtering on boolean values (via json config): It is now possible to add a filter on a measure of type boolean via the json configuration of a view. Support for this type of filter via the UI will be added in a subsequent release.

    Example 45. 

    In the example below a filter is configured such that only those levels are displayed where Active is true:

    {
        "id": "my-view",
        "pivotConfig": {
            "axis": {
              ...
            },
            "filter": {
                "Active": {
                    "type": "equal",
                    "value": true
                }
            }
        }
    }

    Note

    This new feature required us to introduce a new required property type in the metric filter JSON configuration. The following types are supported: range and equal.

    All existing sheets can be automatically migrated using the modeler migration tool. Please follow the upgrade steps listed in the the Upgrade Information section.

Corrected Issues

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

  • Fixed an OutOfMemoryError exception for command line TDX imports with large amount of erroneous data, when no output was specified.

  • Fixed issue in the lb-web-server code that keeps a session with the runtime. Some errors in the session handling were not being properly logged and handled, which could result in lb-web being permanently unable to connect with the runtime.

  • The lb web-server now properly decodes service URLs before pulsing the http control protocol in workspaces during service execution.

  • Adjusted the computation of a transitive closure in lb-workflow's internal data structures to avoid undeterministic behavior that sometimes would lead to very long running rules.

  • Modeler-js:
    • Warming up a canvas containing a sheet without any levels on an axis does not cause an exception anymore.

    • The performance of opening the axis configuration menu has been improved for applications with a very large number of measures/dimensions.

    • The navigationbar as well as an empty workbook table is now presented to users that do not have access to any workbooks.

    • Form mode is now also available in views where there is no level on any axis.

    • Resolved an issue where under certain circumstances calculating values that were entered in deferred calc mode caused an exception.

    • Resolved an issue where the country and region dropdowns are were not marked as required fields in the address form editor.

    • Filtered dropdowns now show a "no matching items" message if the filter metric is empty.

Installation and Upgrade information

Installation Instructions

Install LogicBlox 4.4.5 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.5/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.

Upgrade Information

  • Application projects that are using the measure service config library need to add the library to their project file by adding the following line:

    lb_measure_service_config, library

  • 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-js based 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.4.5 or 4.4.1).

    Note

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

    Example 46. 

    To upgrade a Modeler-js based application from LogicBlox 4.4.1 to 4.4.5, you can run the following command:

    ./node_modules/.bin/migrate-modeler --fromVersion 4.4.1 --toVersion 4.4.5 /path/to/my/modelerapp

Release Information

Server requirements
Operating System: 64 bit Linux; OSX 10.10+ is supported for local development.
Java Runtime Environment 8
Python 2.7 or higher
Client requirements
Applications using modeler-js User Interface Components: Google Chrome or Internet Explorer 11+
Requirements for applications using non-modeler-js components may vary per application.