Expected Behavior Changes for Saving to Mosaic Schema

After saving the Mosaic model to the Mosaic schema, Mosaic models follow the Mosaic schema security and functionality behavior, as follows:

• Missing privilege experience: To save a Mosaic schema, architect-level privileges are required. After saving a schema, the model becomes a schema object. Therefore, the original model owner may lose access and be unable to open the model unless they also have the required architect privileges.

• Data calculation scope: Data queries from attributes and metrics from the Mosaic model may now involve tables from the Mosaic model, as part of the mapped attributes to the Mosaic schema. For a dashboard with only attributes, the result depends on the project schema lookup table that contains the full set of attribute values.

• Engine behavior and calculation logic: When saving a mosaic model to the schema, it now inherits completely the Mosaic Schema query logic. Queries against standalone mosaic models behave differently because some capabilities differ between Mosaic models and Mosaic Schema:

  • Automatic fact degradation: When querying a base metric at a lower level than where it is stored, a standalone Mosaic model automatically obtains the metric by joining the fact table with the relevant relation tables. In a Mosaic schema, you must provide explicit fact extensions, otherwise the query returns an error stating the fact is not available at that level.

  • Auto join behavior: When querying a base metric at an unrelated level, a standalone Mosaic model with Auto-join enabled finds a join path from the fact table to the required attribute through tables with common attributes. If Auto-join is off, the engine cross-joins the fact table with the lookup tables for the analysis level. In a Mosaic schema, you must provide explicit fact extensions. Otherwise, the query returns an error stating the fact is not available at that level.

  • Attribute outer join behavior: The default model-level attribute outer join is ignored and the Mosaic schema's attribute outer join behavior applies instead.

• Functionality differences:

  • YAML export and restore functionality and git versioning functionality are only available for standalone Mosaic models.

  • Copying Mosaic models that are saved to the Mosaic schema are no longer available.

  • Model-level options such as Auto Join, Attribute Outer Join Behavior (which defaults to the source-level behavior), and Calendar (which defaults to the project-level calendar) follow the Mosaic schema logic.

  • If a Hyper card uses an In-Memory Mosaic model and you change the model to Live and save it, the Mosaic schema disables the card.

  • Mosaic models used in Mosaic model linking can not be save to the Mosaic schema.