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: String to Integer String[30] to String[50] 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: String[30] Date	No
	When the attribute is a slob, blob, or primitive array; for example: String[1000] IntegerArray	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 (the only change of type that is allowed)	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.