Generated data model cannot be edited or persisted from the UI
- Dominant language
- Rust
- Stars
- 20.8k
- Forks
- 2.1k
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 181
Description
### **Environment**
- Cube Core (latest)
- Deployment: Docker
- Database: PostgreSQL
### **Problem**
When working with an existing database, Cube generates the initial JavaScript/YAML schema. However, the generated schema often requires manual modifications before it can be used in production.
**Examples include:**
Adding joins between cubes
Defining relationship types
Adding measures
Renaming dimensions
Adding descriptions
Creating calculated members
Adjusting generated SQL
Currently, these changes cannot be made from the Cube Core UI.
The UI only displays the generated schema in a read-only view and instructs users to edit the files inside the mounted Docker volume.
### **Current Workflow**
1. Generate the data model.
2. Open the mounted Docker volume in an external editor (VS Code).
3. Modify the generated JavaScript/YAML files manually.
4. Restart or reload Cube.
5. If the data model is regenerated from the UI, all manual changes are overwritten.
This makes schema iteration cumbersome and discourages using the visual data modeling workflow.
### **Expected Behavior**
Ideally, Cube Core should support one (or both) of the following:
- An editable schema editor directly in the UI.
- Preservation of manual changes when regenerating the data model (or at least prompt before overwriting).
- A merge/update workflow where regenerated metadata is combined with existing customizations.
- The ability to create and manage joins visually from the Data Model UI, similar to semantic modeling tools.
### **Why this matters**
For databases that do not expose complete semantic relationships—or where business relationships need to be modeled manually—the generated schema is only a starting point.
Users are expected to customize the model, but the current workflow requires editing files outside the application, and those customizations can be lost after regeneration.
This makes iterative semantic modeling difficult.
Contributor guide
Research direction
Start with the Data Model UI and the generated JavaScript/YAML schema files in the mounted Docker volume to understand the current read-only and regeneration workflow. Define a focused editing or preservation scope, then verify that customized schemas survive regeneration without unintended overwrites and that the UI clearly indicates the completed state.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, javascript, postgresql
- Domain
- full-stack
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100