Development workspace

The Development workspace is where data builders author models, datasets, and dashboards as AML files. Open it via the Development button in the header.

The workspace surfaces a few standard panels:

• Mode toggle: switch between Production (read-only) and Development. See Code Deployment.
• Branch selector: view and create branches. See Branch Management.
• Code action button: context-aware action (Pull, Commit, Publish). See PR Workflow.
• Project Explore: navigation tree on the left, file content viewer on the right.
• Project Settings: link your project to an external Git provider.
• Source Control: review changes, restore versions, delete branches.

The rest of this page covers the rules specific to writing files in the workspace.

Supported files

Holistics objects live in plain-text files with a .<feature>.aml extension:

File name	Corresponding feature
model_name.model.aml	Data Model
dataset_name.dataset.aml	Dataset
dashboard_name.page.aml	Canvas Dashboard
relationships.aml	Model Relationships
schedules.aml	Query Model Persistence Scheduling
file_name.md	Markdown contents (e.g. README.md)

You can create files of any extension, but only those above have meaning to Holistics.

File names

File names can be arbitrary. All of the following are valid:

orders_master.model.aml
orders master.model.aml
[email protected]

We recommend snake_case.

Allowed characters

• Any Unicode characters except: NUL, \, /, :, *, ?, ", <, >, |
• No space at the start or end of the name
• No period (.) at the end of the name

Object names

Object names (models, datasets, etc.) are stricter than file names:

• Must not start with a number or special character (except _)
• Must not contain spaces or special characters

Valid examples:

order_master
OrderMaster
_order_master
business_metrics

We recommend snake_case.

File names vs. object names

tip

• File and object names don't need to match, but matching them is recommended.
• Renaming an object after it's referenced downstream will break those references.
• File names can be changed freely as long as the object names inside don't change.

A typical use of the file/object split is keeping similarly-shaped models in separate folders:

data_warehouse
    ├── region_asia
    │   ├── orders.model.aml                // contains model orders_asia
    │   ├── products.model.aml              // contains model products_asia
    │   └── business_metrics.dataset.aml    // contains dataset business_metrics_asia
    |
    └── region_europe
        ├── orders.model.aml                // contains model orders_europe
        ├── products.model.aml              // contains model products_europe
        └── business_metrics.dataset.aml    // contains dataset business_metrics_europe

Object names still need to be unique across the project, so use prefixes or suffixes to disambiguate.

Visual vs Code mode

Each file can be viewed in two modes:

• Code mode: plain-text AML, edited directly.
• Visual mode: graphical representation of the file with limited inline edits.

Code mode

Visual mode

The two modes write to the same underlying file. Behavior differs by file type. See the dedicated docs for each feature in the table above.

Project structure

For folder layout conventions, see Project Structure.