No edit summary |
|||
| Line 1: | Line 1: | ||
=== Property inspector for | === Property inspector for a modelled attribute === | ||
[[File:InitalValuesInPropertinspectorForAttribute.png|none|frame]] | [[File:InitalValuesInPropertinspectorForAttribute.png|none|frame]] | ||
==== DefaultDbValue ==== | ==== DefaultDbValue ==== | ||
This is the value used when evolving the database or creating the database. If the attribute is nullable, i.e. has '''Allow Null = true''', the DefaultDbValue is not needed. | |||
This value should be in the format expected by the database engine. | This value should be in the format expected by the database engine. | ||
Examples using SQL Server | Examples using SQL Server: | ||
* Non-nullable [[Documentation:Boolean|Boolean]]: 0 or 1 | * Non-nullable [[Documentation:Boolean|Boolean]]: 0 or 1 | ||
| Line 17: | Line 17: | ||
Initial value used in-memory. Should be a value depending on type of attribute, or nothing/empty for null (if nullable). | Initial value used in-memory. Should be a value depending on type of attribute, or nothing/empty for null (if nullable). | ||
Examples | Examples: | ||
* Non-nullable [[Documentation:Boolean|Boolean]]: false or true | * Non-nullable [[Documentation:Boolean|Boolean]]: false or true | ||
| Line 32: | Line 32: | ||
''Why is the DefaultDbValue needed to even add a non-nullable attribute to the database?'' | ''Why is the DefaultDbValue needed to even add a non-nullable attribute to the database?'' | ||
When evolving a database adding an attribute, the database needs to know what to do with existing rows (i.e. objects). This requires the field to be added with this initial value setting set '''''before evolve'''''. If your | When evolving a database adding an attribute, the database needs to know what to do with existing rows (i.e. objects). This requires the field to be added with this initial value setting set '''''before evolve'''''. If your table is empty, for example, SQL Server will allow the evolve to go through, but you will not be able to add this setting without first dropping the attribute again (see below). | ||
''What if I forget to set nullability to false, and have already added the attribute to my model and evolved?'' | ''What if I forget to set nullability to false, and have already added the attribute to my model and evolved?'' | ||
If you have the field already, but don't need the data, you can rename the field back and forth evolving after each renaming. First drop the attribute/field from the DB and then add it back with the right initial value. | If you have the field already, but don't need the data, you can rename the field back and forth evolving after each renaming. First drop the attribute/field from the DB and then add it back with the right initial value. | ||
Revision as of 06:30, 18 January 2024
Property inspector for a modelled attribute
DefaultDbValue
This is the value used when evolving the database or creating the database. If the attribute is nullable, i.e. has Allow Null = true, the DefaultDbValue is not needed.
This value should be in the format expected by the database engine.
Examples using SQL Server:
- Non-nullable Boolean: 0 or 1
- Non-nullable Decimal: 0 or other value
- String: 'stringvalue' (quoted) (note: strings are always nullable if not using very old database types as char)
Initial value
Initial value used in-memory. Should be a value depending on type of attribute, or nothing/empty for null (if nullable).
Examples:
- Non-nullable Boolean: false or true
- Non-nullable Decimal: 0 or other value
- String: stringvalue (no quotes)
Allow Null
Controls both the in-memory nullability and database attribute setting.
Please note! If this is false, most database engines require a DefaultDbValue to evolve the database. If no value is provided, the existing rows (objects) in database would get an invalid value and the evolve will fail.
More detailed explanation on database creation and evolve
Why is the DefaultDbValue needed to even add a non-nullable attribute to the database?
When evolving a database adding an attribute, the database needs to know what to do with existing rows (i.e. objects). This requires the field to be added with this initial value setting set before evolve. If your table is empty, for example, SQL Server will allow the evolve to go through, but you will not be able to add this setting without first dropping the attribute again (see below).
What if I forget to set nullability to false, and have already added the attribute to my model and evolved?
If you have the field already, but don't need the data, you can rename the field back and forth evolving after each renaming. First drop the attribute/field from the DB and then add it back with the right initial value.