Cubes workspace configuration is stored in a .ini file with sections:
The configuration has changed. Since Cubes supports multiple data stores, their type (backend) is specifien in the store configuration as type property, for example type=sql.
Simple configuration might look like this:
[workspace] model: model.json [store] type: sql url: postgresql://localhost/database
log - path to a log file
warn, info, debug
If not specified otherwise, all cubes share the same default namespace. There names within namespace should be unique. For simplicity and for backward compatibility reasons there are two cube lookup methods: recursive and exact. recursive method looks for cube name in the global namespace first then traverses all namespaces and returns the first cube found. exact requires exact cube name with namespace included as well. The option that affects this behavior is: lookup_method which can be exact or recursive.
The info JSON file might contain:
Section [models] contains list of models. The property names are model identifiers within the configuration (see [translations] for example) and the values are paths to model files.
[models] main: model.json mixpanel: mixpanel.json
If root models_directory is specified in [workspace] then the relative model paths are combined with the root. Example:
[workspace] models_directory: /dwh/cubes/models [models] main: model.json events: events.json
The models are loaded from /dwh/cubes/models/model.json and /dwh/cubes/models/events.json.
If the root_directory is set, then the models_directory is relative to the root_directory. For example if the workspace root is /var/lib/cubes and models_directory is models then the search path for models will be /var/lib/cubes/models. If the models_directory is absolute, for example /cubes/models then the absolute path will be used regardless of the workspace root directory settings.
Model localizations are specified in the configuration with [locale XX] where XX is the locale name. Option names are namespace names and option keys are paths to translation files. For example:
[locale sk] default: translation_sk.json [locale hu] default: translation_hu.json
output with iterable objects, such as facts. Default is 1000. It is recommended to use alternate response format, such as CSV, to get more records.
run by the slicer command)
true for demonstration purposes.
host - host where the server runs, defaults to localhost
port - port on which the server listens, defaults to 5000
allow_cors_origin – Cross-origin resource sharing header. Other related headers are added as well, if this option is present.
authentication – authentication method (see below for more information)
pid_file – path to a file where PID of the running server will be written. If not provided, no PID file is created.
There might be one or more store configured. The section [store] of the cubes.ini file describes the default store. Multiple stores are configured in a separate stores.ini file. The path to the stores configuration file might be specified in a variable stores of the [workspace] section
Properties of the datastore:
Example SQL store:
[store] type: sql url: postgresql://localhost/data schema: cubes
For more information and configuration options see SQL Backend.
Example mixpanel store:
[store] type: mixpanel model: mixpanel.json api_key: 123456abcd api_secret: 12345abcd
Multiple Slicer stores:
[store slicer1] type: slicer url: http://some.host:5000 [store slicer2] type: slicer url: http://other.host:5000
The cubes will be named slicer1.* and slicer2.*. To use specific namespace, different from the store name:
[store slicer3] type: slicer namespace: external url: http://some.host:5000
Cubes will be named external.*
To specify default namespace:
[store slicer4] type: slicer namespace: default. url: http://some.host:5000
Cubes will be named without namespace prefix.
Example configuration file:
[workspace] model: ~/models/contracts_model.json [server] reload: yes log: /var/log/cubes.log log_level: info [store] type: sql url: postgresql://localhost/data schema: cubes
Logging handlers for server requests have sections with name prefix query_log. All sections with this prefix (including section named as the prefix) are collected and chained into a list of logging handlers. Required option is type. You might have multiple handlers of the same time.
CSV request logger options:
SQL request logger options:
Tables are created automatically.
[workspace] model = model.json [store] type = sql url = postgresql://localhost/cubes
Multiple models, one store:
[models] finance = finance.cubesmodel customer = customer.cubesmodel [store] type = sql url = postgresql://localhost/cubes
[store finance] type = sql url = postgresql://localhost/finance model = finance.cubesmodel [store customer] type = sql url = postgresql://otherhost/customer model = customer.cubesmodel