cube-build-model
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseBuild and change a Cube semantic model
构建和修改Cube语义模型
Writes state. The API rejects file writes on any branch that is not a
dev-mode branch, so the branch dance below is not optional ceremony — skip it
and every write fails.
会写入状态。API会拒绝非开发模式分支上的文件写入操作,因此以下的分支操作并非可选流程——跳过的话所有写入都会失败。
Preflight
预检
bash
command -v cube >/dev/null || echo "Cube CLI not installed: curl -fsSL https://raw.githubusercontent.com/cube-js/cube/master/install-cli.sh | sh"
cube whoami || echo "Not authenticated. Interactive: cube login. Headless: set CUBE_API_URL + CUBE_API_KEY."
cube context list # confirm the tenant before writing anythingbash
command -v cube >/dev/null || echo "Cube CLI未安装:curl -fsSL https://raw.githubusercontent.com/cube-js/cube/master/install-cli.sh | sh"
cube whoami || echo "未认证。交互式方式:cube login。无界面方式:设置CUBE_API_URL + CUBE_API_KEY。"
cube context list # 写入前确认租户信息Read before you write
先读取再写入
Never author against an assumed model. Pull the current state first:
bash
cube data-model list <deployment> --content --json > /tmp/model.jsonMatch the project's existing conventions — file layout, naming, whether
measures live on cubes or views, how joins are declared. A correct cube that
looks nothing like its neighbours is a bad contribution.
切勿基于假设的模型进行编写。请先拉取当前状态:
bash
cube data-model list <deployment> --content --json > /tmp/model.json遵循项目现有的约定——文件布局、命名规则、度量是放在立方体还是视图上、关联的声明方式等。一个语法正确但与其他文件风格迥异的立方体是不合格的贡献。
The dev-mode workflow
开发模式工作流
bash
undefinedbash
undefined1. See what branches exist
1. 查看现有分支
cube data-model branches <deployment>
cube data-model branches <deployment>
2. Enter dev mode on a base branch. This forks a personal dev-…
branch
dev-…2. 在基础分支上进入开发模式。这会创建一个个人的dev-…
分支
dev-…and PRINTS ITS NAME. Capture it — writes must target it.
并打印其名称。请记录该名称——写入操作必须指向此分支。
cube data-model dev-mode <deployment> main
cube data-model dev-mode <deployment> main
3. Write files to that branch
3. 向该分支写入文件
cube data-model put <deployment> model/cubes/orders.yml --file ./orders.yml --branch <dev-branch>
cube data-model put <deployment> model/views/revenue.yml --content - --branch <dev-branch> # stdin
cube data-model put <deployment> model/cubes/orders.yml --file ./orders.yml --branch <dev-branch>
cube data-model put <deployment> model/views/revenue.yml --content - --branch <dev-branch> # 标准输入
4. Commit
4. 提交
cube data-model commit <deployment> -m "Add revenue view" --branch <dev-branch>
cube data-model commit <deployment> -m "Add revenue view" --branch <dev-branch>
5. Confirm it actually builds
5. 确认构建成功
cube deployments build-status <deployment> --branch <dev-branch>
cube deployments build-status <deployment> --branch <dev-branch>
6. Leave dev mode when done
6. 完成后退出开发模式
cube data-model exit-dev-mode <deployment>
`--branch` defaults to your active dev-mode branch, so once step 2 has run you
can usually omit it. Pass it explicitly anyway when you are working across
more than one deployment in a session — the default is per-user, not
per-command, and it is easy to write to the wrong place.
Other file operations, same branch rules:
```bash
cube data-model rename <deployment> model/cubes/old.yml model/cubes/new.yml --branch <dev-branch>
cube data-model delete <deployment> model/cubes/dead.yml --branch <dev-branch>cube data-model exit-dev-mode <deployment>
`--branch`参数默认指向你当前的开发模式分支,因此完成步骤2后通常可以省略该参数。但如果在一个会话中同时处理多个部署,请显式传递该参数——默认值是按用户设置的,而非按命令,很容易写入错误的位置。
其他文件操作同样遵循分支规则:
```bash
cube data-model rename <deployment> model/cubes/old.yml model/cubes/new.yml --branch <dev-branch>
cube data-model delete <deployment> model/cubes/dead.yml --branch <dev-branch>Validation is a build, not a linter
验证是构建过程,而非代码检查
There is no offline validate command. The way to know a change is good is to
commit it and read the build:
bash
cube deployments build-status <deployment> --branch <dev-branch>A failing build is the real error message. Report it verbatim rather than
guessing at the cause — Cube's model errors name the file and the member.
After a green build, confirm the change is actually queryable. A measure can
compile and still not be exposed in any view:
bash
cube meta --selectors '[{"type":"cube","deploymentId":<id>,"environment":"<dev-branch>"}]'Then hand off to to check the number is right. Compiling is
not the same as being correct, and a measure whose SQL is wrong builds
perfectly.
cube-run-query没有离线验证命令。确认修改是否正确的方式是提交并查看构建结果:
bash
cube deployments build-status <deployment> --branch <dev-branch>构建失败会返回真实的错误信息。请直接报告错误内容,不要猜测原因——Cube的模型错误会指明文件名和具体成员。
构建成功后,请确认修改内容可被查询。一个度量可能编译成功,但未在任何视图中开放:
bash
cube meta --selectors '[{"type":"cube","deploymentId":<id>,"environment":"<dev-branch>"}]'之后可以使用确认数值是否正确。编译成功不代表内容正确,SQL错误的度量也能完美构建。
cube-run-queryDeploying a local project instead
替代方案:部署本地项目
When the user has the project on disk rather than wanting file-by-file edits:
bash
cube deploy <deployment> # uploads the local directory to the deployment and buildsThis is a different workflow from the dev-mode one above — it replaces the
project from local files. Do not mix the two in one task without saying so.
如果用户本地已有项目,而非需要逐文件编辑:
bash
cube deploy <deployment> # 将本地目录上传到部署环境并构建这与上述开发模式工作流不同——它会用本地文件替换项目内容。请勿在同一任务中混用两种工作流,除非明确说明。
Conventions
约定
- Cubes are the physical layer; views are what users query. New business metrics usually belong on a view, or on a cube and then exposed via a view.
- Keep one cube per file, named after the cube.
- Quote the user's own definition back when you write a expression. If they said "revenue excludes refunds", that belongs in the SQL and in a
sql, not just in the chat.description
- 立方体是物理层;视图是用户查询的对象。新的业务指标通常应放在视图上,或先放在立方体上再通过视图开放。
- 每个文件对应一个立方体,文件名与立方体名称一致。
- 编写表达式时,请引用用户自己的定义。如果用户说“收入不包含退款”,这句话应出现在SQL和
sql中,而不只是聊天记录里。description
When something fails
故障排查
| Symptom | Cause |
|---|---|
| Write rejected | Not on a dev-mode branch — run |
| Rerun the preflight; do not retry the write |
| Build fails after commit | Real model error — read the build status output and fix the named file |
| Change builds but is not queryable | Not exposed in a view; check |
| 症状 | 原因 |
|---|---|
| 写入被拒绝 | 未处于开发模式分支——运行 |
| 重新执行预检步骤;不要重试写入操作 |
| 提交后构建失败 | 真实的模型错误——查看构建状态输出并修复指定文件 |
| 修改构建成功但无法查询 | 未在视图中开放;检查 |