Thus far, the documentation has assumed that developers know the types of objects that they will be dealing with at compile time. More concretely, it has assumed that all SQL table definitions and PDL files have already been defined by the developer. In some situations, however, this assumption is invalid.
Sometimes developers want to provide site administrators with an interface to create their own types of objects and store custom information within the database. Since it is not possible to anticipate all information anyone will ever want to store in the system and it is not feasible to require developers to manually create all types, the system contains the notion of a DynamicObjectType that provides developers with the ability to create data schemas (and persist data to that schema) at run time. This is one of the main motivations of the Metadata-Driven SQL.
The implementation of dynamically storing information has been broken into two parts. The first part, dynamically creating new object types, uses the DynamicObjectType class. The second part, dynamically associating objects to each other, is handled by DynamicAssociation.
In order to provide developers with the ability to declare objects at run time instead of at compile time, the persistence system has the notion of a DynamicObjectType. A Dynamic Object Type allows users to dynamically create and modify Object Types. It can be used to create a subtype of an existing object type, add and remove Attributes and RoleReferences, and perform many other tasks related to the new object type.
The way that this is done is relatively simple. The developer uses methods within the class to set the Model and object type name and create attributes. When the code saves the current object type, it does the following:
Creates the DDL that needs to be executed to store information about the specific object type.
Generates the PDL that needs to be stored so that the object type will be instantiated when the server restarts.
Generates the events for storing information in the schema in memory so that the ObjectType returned can be used within DataObjects.
Executes the DDL to create the schema. Unfortunately, this causes the system to commit the current transaction, so it is important that you do not do anything else in the same transaction as saving the DynamicObjectType.
Assuming the DDL executed successfully, saves the PDL that was generated to a table within the database. The information in this table is then read in on every server startup, so that the DynamicObjectTypes essentially become permanent.
Regenerates events for any children of this object type that may have been affected by any changes that were made.
The DynamicObjectType supports creating new object types. However, it does not allow the dynamic creation of associations that involve static object types. Specifically, if a developer wanted to dynamically create an association between Users and the Publications that they read, the only way to do that would be to add that information to the PDL file, recompile and restart the server. To address this problem, the system provides a DynamicAssociation class.
This class saves information about the association following approximately the same steps as the DynamicObjectType. The main difference between the classes, besides the types of events they generate, is that the DynamicAssociation can be used to map two dynamically defined Object Types, two statically defined Object Types, or one dynamically defined Object Type and one statically defined Object Type. This is in contrast to the DynamicObjectType that only deals with dynamically defined Object Types.