oxy build command processes your semantic layer (views and topics) into CubeJS configuration files and generates embeddings for vector search. It features an intelligent incremental build system that provides 10-100x speedup for small changes.
Quick start
Build modes
The command automatically determines the most efficient build mode based on what has changed:Incremental build (default)
Only rebuilds changed views/topics and their dependencies. This is ~50x faster for single view changes.- Files in
semantics/views/*.view.ymlhave changed - Files in
semantics/topics/*.topic.ymlhave changed - A previous build manifest exists
- Compares current file hashes with previous build
- Identifies modified, added, or deleted files
- Automatically rebuilds dependent views (e.g., if view B references view A’s entity)
- Preserves CubeJS
.cubestorecache for faster startup
No-op build (nothing changed)
Skips the build entirely when no changes are detected. Provides instant feedback (~100ms).- No semantic files have changed
- Database configuration hasn’t changed
- Global settings haven’t changed
Full rebuild
Rebuilds all views and topics from scratch. Clears the CubeJS cache when using--force.
--forceflag is used- No previous build manifest exists (first build)
- Database configuration has changed
- Global settings have changed
Command options
—force, -f
Force a complete rebuild and clear the CubeJS cache.- After database schema migrations
- To clear the CubeJS cache (
.semantics/.cubestore/) - When troubleshooting semantic layer issues
- When you want a clean slate
How it works
Build manifest
The incremental build system maintains a manifest file at.semantics/.build_manifest.json that tracks:
- File hashes: SHA256 hashes of all semantic files
- Output mappings: Which CubeJS files were generated from which source files
- Dependency graph: Relationships between views (e.g., foreign key references)
- Configuration hashes: Database config and global settings for change detection
Change detection
On each build:- Scan
semantics/views/andsemantics/topics/directories - Hash all
.view.ymland.topic.ymlfiles using SHA256 - Compare with previous build manifest
- Detect added, modified, and deleted files
- Expand dependencies using the view relationship graph
- Rebuild only affected views/topics
Dependency tracking
Views can depend on other views through entity relationships:customers.view.yml, the incremental build automatically rebuilds orders.view.yml as well.
Cache preservation
The incremental build preserves the CubeJS cache (.semantics/.cubestore/) to avoid expensive schema recompilation:
- Incremental builds: Cache is preserved (CubeJS picks up changes automatically)
- Natural full rebuilds: Cache is preserved (config/globals change)
- Forced rebuilds: Cache is cleared with
--forceflag
Performance benchmarks
For a large semantic layer with 50+ views:| Scenario | Before | After | Speedup |
|---|---|---|---|
| No changes | ~10s | ~100ms | 100x |
| 1 view changed | ~10s | ~200ms | 50x |
| 5 views changed | ~10s | ~1s | 10x |
| Full rebuild | ~10s | ~10s | 1x |
Embedding management
oxy build also generates embeddings for vector search. Models are downloaded from Hugging Face Hub, so you may need to authenticate:
Troubleshooting
Build manifest corruption
If the build manifest becomes corrupted, the system automatically falls back to a full rebuild:Stale cache after manual edits
If you manually edit files in.semantics/model/ while CubeJS is running, the cache may become stale:
Dependencies not rebuilding
If dependent views aren’t rebuilding when they should, ensure your entity relationships are properly defined:After database migrations
Always run a full rebuild after changing your database schema:Known limitations
- Concurrent builds: Not supported. Running multiple
oxy buildcommands simultaneously may cause corruption. - Manual
.semantics/edits: Overwritten on next build (expected behavior). - Database schema changes: Not automatically detected. Use
oxy build --forceafter migrations. - Cross-view SQL references: Not detected if not using entity relationships. Best practice: use entity relationships instead of raw SQL joins.