Instances
CodeModeler allows to create instances in the persistence layer at production time. This feature is very useful when developers want to initialize specific tables with data.
From the declared instances, the persistence layer producer such as the SQL Server Producer, will produce an extra script containing the creation of the declared instances by using the previously created stored procedure.
Note: No values are automatically created, all of them must be specified by the developer or architect.
For instance, if the entity key is a GUID, you'll need to create the GUID yourself (e.g. you could use the Guid Editor tool) and specify it in the declared instances.
For example, in the following image we have two entities Employee and Address. Address has three instances declared (1, 2, 3) and Employee one which is currently being edited. The employee’s Address instance value can be chosen in a drop-down list because CodeModeler knows there’s a relation between Employee and Address.
By default, an instance is displayed using the entity key instance value (“1”, “2”, “3” in this example). This can be changed as explained in the Instance Editor chapter using another property.
When there’s no property that can represent an instance, it’s also possible to set a custom name for an instance using the “Display Name” instance attribute:
Here we define the “1” instance display name to be “My First Address”. Note this is only a design-time information. It’s not particularly used by a producer as of today.
In this case, it’s easier to use this address when selection an employee’s address as the Address drop-down list now uses the display name:
After a successful build, this is what we can see in the database (if the SQL Server producer was used):
If ever your model contains Blobs (images, documents, etc.), it's possible to create Blob instances as well.
For example, here we have added an employee’s photo:
First you need to 1) add the file as a part to your project, 2) edit or create an instance, and 3) use the browser to point to the file. It’s not mandatory that the blob files are part of the project, but it’s recommended as the project is more portable and is easier to integrate in source controlled and/or team development environments.
After a successful build, this is what we can see in the database (if the SQL Server producer was used). The photo binary data has been saved to the database, along with various metadata:
