Semantic member selection versions

Semantic providers can declare selection_identity_version when changing their member identity encoding. Cube's stable-member-ID adapter requires cube-member-id-v1. Deploy the compatible core library, host, frontend and Cube adapter together; do not roll back to title-keyed code after saving ID-based charts.

Saved Cube selections without this version are rejected, even when a saved title happens to equal a member ID. No historical title mapping is recovered. Open each chart in Explore, choose Start field selection, reselect its metrics, dimensions, filters and sorting, then save. Reset also clears field-dependent formatting; it does not overwrite the saved chart until Save is chosen. Native filters and chart customizations have a separate reset in their configuration form that clears fields, pre-filters, sorting, defaults and dependencies.

Dashboard filters retain their own saved generation. Old filter state and unversioned external member overrides cannot borrow a chart's version. Recreate old dashboard permalink/filter state after reselection. Cross-view overlays are rejected unless their source identity matches the receiving semantic view; matching display titles are not proof of matching members.

The marker is a compatibility contract, not an authorization credential. API clients must rebuild their selections from current member IDs before supplying extras.semantic_selection_version on each query. Providers without a required version retain their existing behavior. No metadata-database migration or automatic rewrite of saved charts is performed.

Programmatic clients must explicitly select current member IDs. Chart-data API queries send extras.semantic_selection_version; name-based datasource queries and MCP get_table requests send top-level semantic_selection_version. Discover the value from datasource metadata (or each external metric returned by MCP list_metrics). The server never adds a missing marker from metadata. Explore query controls remain unavailable until explicit field initialization, so legacy filter subjects cannot trigger value suggestions before reselection.

Custom SQL WHERE and HAVING clauses are not supported on semantic views. Remove those clauses or use semantic dimension filters instead. Chart-data API requests with these clauses return HTTP 400 before querying the provider.

Filter-value suggestions and Matrixify Members and alphabetically sorted All modes use the identity version stored with the chart's selections. After Start field selection and explicit reselection, these controls can load suggested values. Old selections cannot borrow the version from freshly fetched datasource metadata, even when an old title exactly matches a current member ID.

If provenance is missing or stale, suggestions remain unavailable and saved values are preserved. Enter values manually in the filter or Matrixify Members mode, or reset and reselect the fields to restore suggestions.

The column-values API accepts semantic_selection_version as a query parameter. Missing or stale versions on versioned views return an empty result and suggestions_status: "unavailable_versioned_view" before reading cached values or requesting provider values. A matching version enables the existing retrieval and search behavior. Tables and unversioned views keep their existing behavior.

The version is recorded once per chart, not per filter. A filter column added by editing saved form data directly inherits the chart's version, so suggestions are a usability aid for compatible selections, not a guarantee about each filter's provenance. The marker is not an authorization check; access to the datasource is verified separately.