Important use case considerations for using Always On

In Birst, the query language relies on surrogate keys to join a dimension to fact table. If the Parent Space for a Managed Data Mashup (MDM) is an Always On space, the surrogate keys can change when the data is being processed preventing the child space fact table from joining with the Parent space dimension table due to the mismatch of the surrogate keys. A similar case applies for an Always On child space.

Birst does not recommend a use case for MDM when both the Parent and Child spaces are Always On spaces as the surrogate keys are not guaranteed to be consistent when the spaces are being processed.

Note: Modeler Networking does not rely on surrogate keys to join Parent Child tables.

Reports and reports published on a dashboard should always display data, and you should be able to apply dashboard's filters/prompts when processing an Always On space.

  • A known issue is that you cannot query reports & reports published on dashboards during data processing for normal spaces. In these scenarios, the Always-On feature ensures high availability and simultaneous access to reports and dashboards while a space is processing.
  • There is a scenario where you do not have access to data for a period of time (10-15 seconds) in an Always-On space, depending on the size of the space metadata during post data processing steps.
  • An error message may display stating "No data returned. Try changing filters" with reports and reports published on dashboard during post-processing steps such as repository initialization, clearing cache, reloading repository, and so on. During this process, dashlets are temporarily unavailable. Additionally, the space needs a few seconds post-processing to perform space context loading activities.