¶ Template architecture and lifecycle
Templates are used for two goals:
- speed up OT/DT design
- enforce required structure for specific integrations
A template can define:
- required and optional columns
- allowed references and parents
- recommended or fixed names
- recommended or fixed flags
- recommended or fixed settings
- allowed customizations (or explicit prohibition)
For both object-structure templates and data-table templates:
- template
- template version
- version columns
- column specs
A template version is the key unit used during OT/DT creation.
Template version state can be:
- Inactive
- Active
- Deprecated
Practical meaning:
- Inactive: not for normal usage.
- Active: standard version for new structures.
- Deprecated: still recognized but marked for migration to a replacement version.
Template model separates:
- template-defined defaults/recommendations
- chosen values applied to final OT/DT
This enables:
- strict enforcement where required
- controlled flexibility where allowed
Template flags can lock values so architects cannot override them during wizard:
- fixed data type
- fixed size
- fixed min/max/regex
- fixed selected flags
- fixed connected-column references
- fixed table-level settings
This is the main mechanism for integration compliance (for example driver-specific schemas).
¶ Parent and reference strategy
Template versions can restrict:
- allowed parent template versions
- allowed reference target template versions
- custom parent/reference allowance
This prevents semantically invalid schema combinations.
¶ Project visibility and rights
Template access can be configured:
- default for all projects
- explicitly per project
Project-level template rights distinguish basic usage from management/administration.
Once template versions are used in generated OT/DT, unsafe edits should be avoided.
Recommended strategy:
- Create a new version.
- Mark old version as Deprecated.
- Set replacement target version.
- Migrate projects gradually.