Special behaviors for entity types during instantiation

There are special behaviors for instantiating Guidewire entity types, which are Gosu types that you define by editing data model XML configuration files.

Required Fields During Instantiation

In data model configuration XML files, you can declare required properties for an entity type during object instantiation. To specify a required entity property is required, set the attribute called required to the value true. The default is false. The required attribute is supported on the <column>, <typekey>, and <foreignkey> definitions of an entity type.

The required attribute does not overlap with the behavior of the attribute called nullok. The nullok attribute affects only the value of that property at commit time, which is the time the object is written to the database. In contrast, the required attribute affects only object instantiation. If the required property is an object type, the value must be non-null at the time of object instantiation to prevent Gosu throwing an exception.

Code that uses the new operator to instantiate an entity type must include all required properties when constructing an instance of that entity as arguments to the constructor. If the constructor has other constructor arguments, the required properties appear after those other arguments.

For example, suppose an entity called MyEntity has one required parameter that is has type Address. The expression new MyEntity() is a compilation error because the required property is missing from the argument list. To fix the error, get a reference to a non-null Address entity instance and pass it to the constructor, such as:

var e = new MyEntity(myAddress)

Optional bundle argument during instantiation

By default, Gosu creates the new entity instance in the current database transaction. Gosu represents the database transaction as a set of entity instance changes encapsulated in a Gosu object called a bundle. In nearly all PolicyCenter contexts, this is the best behavior. For example, PolicyCenter correctly rolls back all changes to the database in that transaction if any errors occur before the entire set of changes commit to the database.

Providing a specific bundle during entity instantiation is appropriate only in rare cases in application logic. For example, there are rare cases where there is no current database transaction or an action must be handled asynchronously in a different thread. For these rare cases, pass the bundle as the final argument to the new operator expression.

The following table lists the behavior of the new operator with different parameters:

Extra database transaction parameter to `new` operator	Meaning	Example
No extra parameter	Create the entity in the current database transaction, which is the current bundle. In almost all cases, use this approach.	`new Note()`
Reference to a bundle	Create the entity instance in the current database transaction indicated by the bundle passed directly to the `new` operator. The bundle must be writable, for example it cannot be a read-only bundle associated with a database query result.	`new Note(myPolicy.Bundle)`
Reference to a Guidewire entity	Create the entity instance in the same database transaction as the entity passed as a parameter. The bundle must be writable, for example it cannot be a read-only bundle associated with a database query result.	`new Note(myPolicy)`

Warning: Be extremely careful if you use bundle and transaction APIs to override the default behavior for bundle management.

Interaction between bundle parameter and required fields

If an entity type has required fields and you need the optional instantiation parameter for the bundle, the constructor argument list must include the bundle parameter before any required properties.