OplogConfig
Configure oplog (semantic-model-management) recording on deploy.
enabled is the opt-in toggle: when true, a successful
rai models deploy also records the change to the model’s oplog (and
pull / branch / merge become available). It defaults to
false while the feature rolls out — set oplog.enabled: true in
raiconfig to turn it on. backend selects where the oplog lives:
snowflake (the real _INTERNAL_OPLOG table) or jsonl (a local
file, reserved for tests/demos).
table_type picks the Snowflake table type the oplog is provisioned as.
hybrid is the default because appends are markedly faster on it: a
single-record append measures ~1.2s against a Hybrid Table versus ~2.9s
against a standard one, and the gap is fixed per-transaction overhead, so it
does not shrink for small changesets. Set standard on accounts where
Hybrid Tables are unavailable (e.g. Tri-Secret Secure). Correctness is
equivalent either way: the concurrent-append fork guard is the compare-and-swap
on _INTERNAL_OPLOG_HEAD (RAI-51225), which does not rely on PRIMARY KEY
enforcement. This only affects tables at creation; an already-provisioned
oplog keeps the type it was created with.
Inheritance Hierarchy
Referenced By
RelationalAI Documentation ├── Build With RelationalAI │ └── Understand how PyRel works > Configure PyRel │ └── Configure a model └── Release Notes └── Python API Release Notes └── What’s New in Version 1.16.0 └── New Features and Enhancements