TheDocumentation Index
Fetch the complete documentation index at: https://oxy.tech/docs/llms.txt
Use this file to discover all available pages before exploring further.
oxy build command processes your semantic layer (views and topics) 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 semantic layer cache 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 semantic layer 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 semantic layer cache.- After database schema migrations
- 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 semantic layer 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 semantic layer cache to avoid expensive schema recompilation:- Incremental builds: Cache is preserved
- 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/, 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.