Application Upgrades

Casabase Cube is distributed as a Snowflake Native Application.

Application upgrades follow the Snowflake Native App lifecycle: the provider publishes a new version and the installed application moves to that version.

The upgrade replaces application code while preserving customer-specific cube state such as:

• Cubes
• Dimension definitions
• Formulas
• Data
• Security rules
• Data classifications
• Saved Queries
• Schedules
• Audit history

Upgrade Model

Casabase Cube upgrades are automatic from the application’s perspective.

There is no separate manual Casabase Cube migration process that an administrator must run after the Native App version changes.

Conceptually:

New Application Version
        │
        ▼
Native App Upgrade
        │
        ▼
Replace Application Code
        │
        ▼
Run Required Migrations
        │
        ▼
Rebuild Managed Structures
        │
        ▼
Validate Each Cube

The application performs the version-specific migrations required by the new release.

Checking the Installed Version

Casabase Cube stores version metadata in:

CONFIG.APP_METADATA

To review the current and previous versions:

SELECT
    KEY,
    VALUE,
    UPDATED_DATE
FROM CASABASE_CUBE.CONFIG.APP_METADATA
WHERE KEY IN (
    'VERSION',
    'PREV_VERSION'
);

Substitute your installed application name for:

CASABASE_CUBE

where appropriate.

The two key values are:

VERSION
PREV_VERSION

These provide a straightforward way to confirm whether the installed application version changed.

Reviewing Upgrade History

Application upgrades are recorded in the Casabase Cube audit log.

To review recent upgrade history:

CALL CUBE.EXPORT_AUDIT_LOG(
    NULL,
    NULL,
    'APP_UPGRADE',
    NULL,
    50
);

For an APP_UPGRADE event, the DETAILS field contains version information such as:

{
  "previous_version": "...",
  "new_version": "..."
}

Upgrade-related audit events include:

APP_UPGRADE
UPGRADE_MIGRATION

These events provide both the application-level version transition and information about migration activity.

What Happens During an Upgrade

When the application version changes, Casabase Cube:

• Replaces procedure and application code with the new version
• Runs migrations required by the new version
• Rebuilds the internal formula cache for each cube
• Recreates <CUBE>_DIMENSIONS
• Recreates <CUBE>_FACT_SECURE
• Removes application objects superseded by renames
• Records APP_UPGRADE and UPGRADE_MIGRATION events in the audit log

Conceptually:

Old Version
    │
    ▼
Replace Application Code
    │
    ▼
Run Version Migrations
    │
    ▼
Rebuild Formula Cache
    │
    ▼
Recreate Secure Views
    │
    ▼
Remove Superseded Objects
    │
    ▼
Record Audit Events

What Persists

Application upgrades preserve customer-specific logical state.

For example:

Application Code
      │
      └── Replaced


Customer Cubes
      │
      └── Preserved


Dimension Definitions
      │
      └── Preserved


Formulas
      │
      └── Preserved


Data
      │
      └── Preserved


Security Rules
      │
      └── Preserved


Audit History
      │
      └── Preserved

This means an application upgrade is not a cube migration or data reload.

The existing customer model remains while the Native App code and managed implementation structures move to the new version.

Fresh Installs

Fresh installations do not run upgrade migrations.

Migration logic applies when moving an existing installation from one application version to another.

Per-Cube Migration Failures

An important upgrade behavior is that a migration failure for one cube does not necessarily abort the entire application upgrade.

Per-cube migration failures are:

Counted
+
Written to the Audit Log

while the overall application upgrade can still complete successfully.

This means:

A successful Native App upgrade does not by itself prove that every cube completed every required migration successfully.

Post-upgrade validation is therefore required.

After an Upgrade

The definitive verification sequence is:

1. Confirm VERSION changed
        │
        ▼
2. Review APP_UPGRADE / UPGRADE_MIGRATION
        │
        ▼
3. Run HEALTH_CHECK
        │
        ▼
4. Run a Known Query
        │
        ▼
5. Check Scheduled Queries

1. Confirm the Version

Verify that the application moved to the expected version:

SELECT VALUE
FROM CASABASE_CUBE.CONFIG.APP_METADATA
WHERE KEY = 'VERSION';

If required, compare this with:

PREV_VERSION

or the version recorded before the upgrade.

2. Check Migration Events

Review recent upgrade and migration activity:

SELECT
    CREATED_AT,
    STATUS,
    OBJECT_NAME,
    DETAILS,
    ERROR_MESSAGE
FROM CASABASE_CUBE.CONFIG.AUDIT_LOG
WHERE EVENT_TYPE IN (
    'APP_UPGRADE',
    'UPGRADE_MIGRATION'
)
  AND CREATED_AT > DATEADD(
        'day',
        -1,
        CURRENT_TIMESTAMP()
      )
ORDER BY CREATED_AT DESC;

Pay particular attention to:

STATUS
OBJECT_NAME
ERROR_MESSAGE
DETAILS

because a cube-specific migration issue can require attention even when the overall application upgrade completed.

3. Run a Health Check

Run:

CALL CUBE.HEALTH_CHECK('FINANCE');

for each important cube.

To validate all cubes, you can also use:

CALL CUBE.HEALTH_CHECK(NULL);

The health check is especially useful after an upgrade because it validates application-managed structures, query support objects, formula configuration, and stale external AI-agent state.

See Health and Diagnostics.

4. Run a Known Verification Query

For each production cube, keep at least one known query whose expected result is understood.

After the upgrade:

Run Verification Query
        │
        ▼
Compare with Expected Result
        │
        ├── Matches ──► Continue
        │
        └── Differs
                │
                ▼
        Investigate Migration /
        Configuration / Behavior Change

explicitly recommends keeping one verification query per cube ready before the upgrade.

For important cubes, the verification query should exercise representative functionality rather than merely proving that QUERY_CUBE executes.

Depending on the cube, that can include:

• Hierarchy aggregation
• Calculated members
• Default members
• Time intelligence
• Security
• Saved Query behavior

5. Check Scheduled Queries

Confirm that scheduled Saved Queries are still operating:

CALL CUBE.LIST_SAVED_QUERY_SCHEDULES(NULL);

Review:

• Schedule state
• Last-run status
• Errors
• Target tables
• Expected refresh behavior

If an output table’s expected shape changed because of the application release, rerun the materialization.

Materialized Tables After an Upgrade

Materialized reporting tables are customer-consumable outputs containing the shape produced by the Saved Query when they were last written.

An application upgrade does not automatically rewrite every already-materialized result table to reflect a changed output shape.

If the expected columns changed, rerun the scheduled query:

CALL CUBE.RUN_SCHEDULED_QUERY(
    'FINANCE',
    'Monthly Report'
);

Conceptually:

Old Materialized Result
        │
        ▼
Application Upgrade
        │
        ▼
Query Definition / Output Behavior Changed?
        │
        ├── No ──► Existing Table May Remain Valid
        │
        └── Yes
               │
               ▼
        Run Scheduled Query
               │
               ▼
        Replace Result Table

Snowflake Intelligence and Cortex Agent Validation

The current Casabase Cube Intelligence integration uses an app-created Cortex Agent within the Snowflake Native App model.

For health checks and post-upgrade validation, confirm:

• The app-created agent is available.
• Required Cortex Agent and Snowflake Intelligence capabilities are enabled in the account.
• Intended Snowflake account roles hold the appropriate Casabase Cube application role.
• The user’s default role has the required Cortex Agent and warehouse privileges.
• Required privileges and caller grants for consumer-owned objects are present where applicable.
• A representative Snowflake Intelligence question can invoke the intended Casabase Cube tools successfully.

Customer-created views, BI models, saved SQL, and other external objects that reference application objects by name remain customer-owned and should be validated separately after application upgrades.

See Setting Up the Agent and Governance and Security.

Customer Views and BI Models

Customer-created views, BI models, and saved SQL can contain references to specific Casabase Cube object names.

If a release renames a supported object, those external references cannot be rewritten automatically by the Native App.

Administrators should therefore:

Read Release Notes
        │
        ▼
Identify Renamed Interfaces
        │
        ▼
Find Customer Objects Referencing Them
        │
        ▼
Repoint Those Objects

specifically calls out customer-created views, BI models, and saved SQL as upgrade responsibilities outside the application’s control.

Planning an Upgrade

Before an upgrade:

• Read the release notes for object renames and behavioral changes.
• Upgrade a non-production installation first where one exists.
• Prefer a quiet window because migrations can touch every cube.
• Export production cube configuration as a rollback reference.
• Prepare one verification query per cube with a known expected result.

Export Configuration Beforehand

Use:

CALL CUBE.EXPORT_CUBE_CONFIG('FINANCE');

before an upgrade to preserve a configuration reference.

The export is useful for:

• Change review
• Troubleshooting
• Configuration comparison
• Rollback reference

It should not be interpreted as meaning that normal application upgrades erase cube configuration. The configuration persists through the upgrade.

Quiet-Window Planning

recommends preferring a quiet window because upgrade migrations can touch every cube.

This is different from a traditional OLAP outage model.

There is no separate application-server estate to patch, but migration work can still consume Snowflake resources and alter application-managed structures.

For important production environments, schedule the change at a time appropriate for the expected workload and validation effort.

Upgrade Audit Trail

Casabase Cube provides an application-level upgrade history through:

APP_UPGRADE
UPGRADE_MIGRATION

events.

This allows administrators to answer questions such as:

When did the application upgrade?
What version changed?
Which cube migration ran?
Did it succeed?
Was an error recorded?

The audit history should be included when investigating unexpected post-upgrade behavior.

See Audit Log.

What an Upgrade Does Not Require

A normal Casabase Cube application upgrade does not require:

• Exporting customer analytical data to Casabase
• Moving customer data outside Snowflake
• Rebuilding a separate OLAP server environment
• Reinstalling a Casabase-specific driver
• Running an external migration utility
• Manually recreating every cube
• Manually reloading all fact data

The Native App performs the required internal application migration within Snowflake.

Key Principle

The most important operational point is:

An application upgrade can complete successfully even when an individual cube migration requires attention. Always perform post-upgrade validation.

The reliable workflow is:

Upgrade Completes
       │
       ▼
Confirm Version
       │
       ▼
Inspect Migration Events
       │
       ▼
Validate Cube Health
       │
       ▼
Validate Known Results
       │
       ▼
Validate External Dependencies

Related Topics

• Administration Overview
• Health and Diagnostics
• Audit Log
• Operational Tasks
• Saved Queries
• Integration Points
• Data Storage & Boundaries