Design-Time Dynamic Property Use
The following table summarizes the conditions that require a database reorganization when using design‑time dynamic properties. Reorganization is required only when a class has instances, so an implied condition for the table is that there are instances of the class containing the design‑time dynamic property.
When there are no instances, there is no advantage in using a design‑time dynamic property.
| Action on Design‑Time Dynamic Property | Condition | Reorg is Required |
|---|---|---|
| Adding an attribute | No | |
|
Changing an attribute |
When the attribute is a primitive type; for example:
The type of a primitive‑array attribute cannot be changed. |
No |
|
Deleting an attribute |
When the attribute is not a slob, blob, or primitive array; for example:
|
No |
|
|
When the attribute is a slob, blob, or primitive array; for example:
|
Yes |
|
Adding a reference |
When the reference does not have an inverse |
No |
|
|
When the reference is made an inverse of an existing reference |
Yes |
| When the reference and its inverse are dynamic, and both are added at the same time |
No | |
|
Changing a reference |
When the reference is changed to a superclass type |
No |
| Deleting a reference | When the reference does not have an inverse | No |
| Deleting a reference | When the reference is an inverse reference | Yes |
| Changing a condition used as a constraint |
Yes |
One reason for preferring design‑time dynamic properties over static properties is to avoid a lengthy database reorganization. For more details, see "Deciding Between Static and Design‑Time Dynamic Properties", later in this chapter.
