- Export converts a Cube data model to one Ossie model: the YAML data model of a deployment’s latest successful build, or YAML files you upload, such as a local checkout.
- Import converts an Ossie model to Cube data model files.
What converts
An export with
view converts only the public members of that view, under the names the view
gives them. A whole-model export keeps its views in the Ossie model’s Cube extensions.
Cube features with no Ossie equivalent, such as segments, pre-aggregations, hierarchies, access
policies and view curation, are kept in the Ossie model’s Cube extensions, so importing the model
back into Cube restores them. Other tools ignore them. On import, Ossie features with no Cube
equivalent are kept under meta.ossie where Cube has room for them and reported as warnings where
it does not.
Issues
Every conversion returns a list of issues:ERROR: the conversion failed and returned no files, for example a cube that usesextends.WARNING: something was dropped or changed, for example a skipped Jinja-templated file or a measure whose value can change when a join fans out.INFO: something was kept in another form, for example ageodimension split into latitude and longitude fields.
sum or avg, read through a join that fans out, converts with a warning, since
an Ossie expression cannot carry Cube’s fan-out correction. Set strictFanout to true in the
conversion request to fail instead. It defaults to true for a view export and false otherwise.
Limits
- Only static YAML models convert. JavaScript models and Jinja-templated files are skipped.
- An upload holds at most 512
.ymlor.yamlfiles: each file up to 2 MiB, and 20 MiB in total. An Ossie model is at most 2 MiB. - Each conversion has 60 seconds to run. Conversions and their results are kept for at most one day.
- Each user can run two conversions at a time and start six a minute. Over either limit, the API
answers
429with aRetry-Afterheader.
Convert with the Platform API
Use a Platform API key withSchemaRead or SchemaUpdate
access to the deployment. The endpoints are under
/api/v1/deployments/{deploymentId}/ossie-conversions.
Start a conversion with POST. For an export of the deployment’s data model, send
{"direction": "export"}, and add "view": "<name>" to export one view. To export your own files,
send "source": "files" and files, a map of relative paths to YAML. For an import, send
{"direction": "import", "ossieYaml": "<document>"}. On import, dialect picks which warehouse SQL
to take from the Ossie model, and defaults to the dialect of the deployment’s default data source.
The response is 202 with a conversionId, a statusUrl and a resultUrl. Poll GET on the
statusUrl until the status is no longer QUEUED or RUNNING:
COMPLETED: the conversion produced a result. Itsoutcomeissuccessorfailed.FAILED: the conversion ended without a result;errorsays why.CANCELLED: the conversion was cancelled withDELETEon thestatusUrl.
GET on the resultUrl returns the counts and issues, and GET …/{conversionId}/files returns
the files: ossie.yaml for an export, or the Cube data model files for an import. Both answer
409 until the conversion’s result is available, which can be a moment after the status first
reads COMPLETED, so retry a 409 briefly.
This example exports the deployment’s data model and requires curl and jq. Set CUBE_API_URL
to your tenant host without a trailing slash, DEPLOYMENT_ID to the deployment, and
CUBE_API_TOKEN to the API key.