You use Initial value, DefaultDbValue, and Allow Null on a model attribute to control the value of a new in-memory object, the database column definition, and whether a value is required.
Set these properties in the attribute's property inspector in MDriven Designer. They solve related but different problems:
| Property | Controls | Value format | Example for a Boolean |
|---|---|---|---|
| Initial value | The value assigned when MDriven creates a new object in memory. | A value in the attribute's model type format. Leave it empty for null when the attribute is nullable. | false
|
| DefaultDbValue | The value the database uses when MDriven creates or evolves the database column. | A value or expression in the syntax expected by the database engine. | 0
|
| Allow Null | Whether the attribute can be null in memory and whether the database column accepts null. | true or false
|
false makes the attribute required.
|
Choose the right property
Use Initial value when a new object should start with a value before it is persisted.
For example, a new Order object can have a non-nullable Boolean attribute IsApproved with an Initial value of false. Code and expressions working with the new object in memory see false.
Use DefaultDbValue when the database needs a default while creating or changing its schema. This is especially important when you add a required attribute to a table that already contains rows.
For example, when you add the non-nullable IsApproved attribute to existing orders in SQL Server, use:
| Attribute property | Value |
|---|---|
| Allow Null | false
|
| Initial value | false
|
| DefaultDbValue | 0
|
The Initial value gives newly created in-memory orders false. The DefaultDbValue gives SQL Server a value to place in existing database rows while it adds the required column.
Set values when creating a new attribute
- Select the attribute in the model and open its property inspector.
- Decide whether the attribute may be null. Set Allow Null to
trueorfalse. - If new objects need a value in memory, enter an Initial value in the model type's format.
- If the attribute is non-nullable and you will create or evolve an SQL database, enter a DefaultDbValue in the target database's format.
- Evolve the database after the properties are set.
If an attribute is nullable (Allow Null = true), a DefaultDbValue is not required for the column to accept null. You may still choose a database default where that is appropriate for your database design.
Why a required attribute needs a database default during evolve
Database evolution changes an existing database to match the model. When you add a new column to a table that already has rows, every existing row needs a value for that column if the column is non-nullable.
For example, assume the database already contains 500 Order rows and you add:
Order.IsApproved : Boolean
Allow Null = false
Without a DefaultDbValue, the database has no valid value to put in IsApproved for those 500 rows, and the evolve can fail. Set DefaultDbValue = 0 for SQL Server before evolving so that existing rows receive a valid value.
An empty table can allow an evolve to succeed without this value in some cases. Do not rely on that when designing a required persisted attribute: set the DefaultDbValue before the first evolve that adds the column.
Value formats
Initial value and DefaultDbValue are interpreted in different places. Do not copy the same text between them without checking the required format.
| Attribute type | Initial value (in memory) | DefaultDbValue for SQL Server |
|---|---|---|
| Non-nullable Boolean | false or true
|
0 or 1
|
| Non-nullable Decimal | 0 or another decimal value
|
0 or another database-valid value
|
| String | stringvalue
|
'stringvalue'
|
For strings, the Initial value has no quotation marks, while the SQL Server DefaultDbValue is quoted. Strings are normally nullable unless you use very old database types such as char.
For a persisted Boolean, use a non-nullable Boolean in most cases. In MDrivenServer persistence mapping, a Boolean is represented by a bit in the database: 1 is true and 0 is false. See Documentation:Boolean and Documentation:Case sensitive or not.
Correct an attribute that was evolved with the wrong nullability
If you evolved an attribute as nullable and later need it to be required, first decide whether existing values must be retained.
- If the data must be retained, plan a data migration before making the attribute non-nullable. Existing nulls must be handled before a required database column can be used.
- If the data is not needed, the documented recovery approach is to rename the attribute, evolve after each rename so the old database field is removed, and then add the attribute again with the intended Allow Null, Initial value, and DefaultDbValue settings before evolving.
Do not change an existing required attribute to non-nullable without considering the rows already stored in the database.
These properties concern modeled attributes and SQL database persistence. Database behavior and DefaultDbValue syntax depend on the database engine. This page uses SQL Server examples; use syntax valid for your target database.
For persistence mapping behavior beyond attribute defaults, see Documentation:Working with Code and Persistence Mapping. For production database connection and database-engine setup, see Documentation:Configuring Production Databases PostgreSQL MySQL MSSQL.