EC Schema Validation

The variability and potential magnitude of schema rules lead to the need for quality control and long-term maintainability over EC schemas.

EC v3

EC v3 is a more clearly defined and rigorous version of the EC that has been used widely in Bentley over the past 10+ years.

An ECSchema describes one "domain"—its primary contents are a closely related set of "ECClasses" of various kinds.

Unless noted otherwise, all references to “schema”, “class” and “property” in this document refer to ECSchema, ECClass and ECProperty.

EC Schemas are validated against a set of rules. If one rule is violated, the whole schema will fail validation.

The rules are broken into the different parts of the Schema they are validated against.

A class may not not derive from a sealed base class.

A class may not derive from a base class of a different EC type (i.e. EntityClass => RelationshipClass).

A abstract class may not derive from a non-abstract base class.

A CustomAttribute applied to a container must be of a concrete (non-abstract) class.

The type of the enumeration must be either a String or an Integer.

The class that a Mixin is applied to must satisfy the Mixin applies to constraint.

Property overrides cannot change the property's value type (ie. String, Integer, Boolean, etc.)

Property overrides cannot change the property's type (ie. PrimitiveProperty, EnumerationProperty, StructProperty, etc.)

Property overrides cannot change the persistence unit.

A derived Relationship's abstract constraint must be supported by the base Relationship class constraint(s).

A derived Relationship's class constraint(S) must be supported by the base Relationship class constraint(s).

The constraints of a RelationshipClass must derive the the abstract constraint class.

Relationship constraints must contain at least one constraint class.

An abstract constraint is required if a Relationship constraint has multiple constraint classes.

Last Updated: 15 June, 2021