Publicity of data model entities
The data model serves as a facade of your data and enables running queries via a rich set of APIs by referencing data model entities: cubes, views, and their members. Controlling whether they are public or not helps manage data access and expose a coherent representation of the data model to end users.
By default, all cubes, views, measures, dimensions, and segments are public, meaning that they can be used in API queries and they are visible during data model introspection.
Managing publicity
You can explicitly make a data model entity public or private by setting its
public
parameter to true
or false
. This parameter is available for
cubes, views, measures,
dimensions, and segments.
In development mode and in Playground, access
control checks are disabled and all public
parameters are ignored. It helps
you conveniently debug the data model by using private data model entities in
API queries and during data model introspection.
Dynamic data models
You can also control whether a data model entity should be public or private dynamically.
In the example below, the customers
view would only be visible to a subset
of tenants that have the team
property set to marketing
in the security context:
views:
- name: customers
public: "{{ is_accessible_by_team('marketing', COMPILE_CONTEXT) }}"
from cube import TemplateContext
template = TemplateContext()
@template.function('is_accessible_by_team')
def is_accessible_by_team(team: str, ctx: dict) -> bool:
return team == ctx['securityContext'].setdefault('team', 'default')
If you'd like to keep a data model entity public but prevent access to it
anyway, you can use the query_rewrite
configuration option for that.
Best practices
Cubes and views
If your data model contains both cubes and views, it's recommended to keep cubes private and only expose views to visualization tools. Doing so, you will have more control over queries that can be run against the data model.
Members
If you have measures or dimensions that are not intended to be exposed to end users, it's recommended to keep them private. Often, such auxiliary members would be used in calculated measures and dimensions.
cubes:
- name: users
sql_table: users
dimensions:
- name: first_name
sql: first_name
type: string
public: false
- name: initial
sql: "LEFT({first_name}, 1)"
type: string