Templates accelerate OT/DT design and enforce required structure for integrations.
Template
└── Template Version (state: Inactive / Active / Deprecated)
├── Version Column (column type, required flag)
│ └── Column Spec (data type, size, validation, flags, settings)
├── Allowed parents (restrict which OT versions can be parent)
└── Allowed references (restrict which OT versions can be referenced)
Both object-structure templates and data-table templates follow this model.
| Aspect | Template can define |
|---|---|
| Columns | Required and optional columns with types, data types, validation |
| Names | Recommended or fixed |
| Flags | Recommended or fixed (table-level and column-level) |
| Settings | Recommended or fixed |
| Relations | Allowed parents and references |
| Customization | Allow or prohibit additional columns |
| State | Meaning |
|---|---|
| Inactive | Draft, not available for normal use |
| Active | Standard version for new OT/DT creation |
| Deprecated | Still recognized, but marked for migration (can set replacement version) |
The template model separates template-defined defaults from chosen values applied during OT/DT creation:
Template authors can lock specific properties with fixed_* flags:
| Fixed flag | Prevents override of |
|---|---|
| Fixed data type | Column data type |
| Fixed size | Column size/precision |
| Fixed min/max/regex | Validation rules |
| Fixed flags | Selected column flags |
| Fixed connected-column | Connected-column references (DT) |
| Fixed settings | Table-level settings |
This is the main mechanism for integration compliance (e.g., driver-specific schemas).
Template versions can restrict:
This prevents semantically invalid schema combinations.
Template access per project can be:
Project-level template rights distinguish basic usage from management.
Once a template version is used in generated OT/DT, avoid breaking edits.