Entity Editor, Fields Tab

The Fields tab of the Entity Editor contains the information and editors for working with the fields of the entity, the unique constraints defined over these fields and the Fields mapped onto Related Fields. The different parts are contained in three horizontal sub-tabs which are described below.

Entity Fields sub-tab

This sub-tab shows the fields defined in the entity. The fields are shown in a grid, and directly editable. To add a new field, click in the top-row of the grid or (when the grid already has focus) press Ctrl-Shift-F to add a new field to the entity. You don't have to specify all the columns, only the first two, Name and Type are mandatory.

When you've specified enough information for the field, press Ctrl-Enter to add the field. A new field will automatically get a target field mapped, if the designer can find an unmapped field in the mapped target element (if the entity is mapped to a target (table/view) already) matching the newly added field.

Editing fields uses type shortcuts for specifying types easily. You can type the first characters of the type shortcut to make the grid automatically pre-select the type(s) matching the characters typed, like intellisense. Pressing TAB will move the focus to the next column. To edit the Description, move to that column using TAB or cursor keys and press Ctrl-DownArrow to open the small text editor to specify a description for a field. Descriptions are generated as XML DOC comments into the output.

To remove one or more fields, you have to select the fields using the row headers in the grid and click the Remove selected button at the bottom of the subtab.

To set the field order for the fields, click the Set Field Ordering button, which will bring up the Field Order Selector to specify the field ordering for the entity.

Refactoring fields

The designer supports refactoring of entity definitions by offering a small set of refactoring options for one or more selected fields. To perform a particular refactoring, select one or more fields to which the refactoring will be applied and click the Refactor selected... button at the bottom to select the refactoring from the list of available refactorings.

Not all refactorings are available at all times, only the ones which make sense for a particular situation: inheritance oriented refactorings aren't available when the entity isn't in an inheritance hierarchy.

The following refactoring options are available:

Bounce Value Types in Selected to Local Fields

This refactoring will for each field in the list of selected fields replace that field with all the fields of the Value Type Definition it has as its type. If a field has a .NET type, it's not refactored. This refactoring can be useful when you have set the type of a field to a Value Type Definition but now you rather want to have the fields of the Value Type Definition local to the entity. It's the opposite of the refactoring Convert Selected into Value Type.

Convert Selected into Value Type

This refactoring creates a new Value Type Definition (using the information you specify in the popup dialog shown) with the fields selected in the entity editor and replaces all selected fields with a new field which type is set to the just created Value Type Definition. Example: entity Customer has several fields which combined form an Address. Select all those fields in the grid on the Entity Fields sub-tab and select the refactoring Convert Selected into Value Type. As name for the new value type, specify AddressVt. This creates a new Value Type Definition AddressVt, adds to it all the fields selected in Customer, creates a new field into Customer, of type AddressVt and removes all selected fields from Customer. The designer will also make sure the fields are properly mapped, if applicable.

Move Selected to Subtype / Supertype

This refactoring moves the selected fields to either the selected subtype or selected supertype, correcting mappings along the way.

Replace selected fields with existing value type

This refactoring replaces the selected field(s) in the field editor with a matching existing Value Type. This refactoring is similar to Convert Selected into Value Type, however instead of creating a new Value Type, it uses an existing Value Type, if available. Which value types are offered through the refactoring menu depends on a couple of factors:

• The value type must be in the list of field types offered in the field editor. This is a safe way to filtering out value types which could lead to a cycle. As the field which will be a field like any other in the element and it will get the type of the valuetype chosen, it's equal to selecting a field's type through the list of available field types.
•  The value type must have the same number of fields selected and the types must match, and if there are multiple fields with the same type, the field names, lower case compare, must be equal. Example: if there are two fields selected, F1 and F2, both string, and there's a valuetype with two string fields F1 and f2, it is a match. This might be very strict, but it's otherwise a gamble: if there are two fields with the same type, it's not possible to replace them with fields inside a valuetype

Unique Constraints sub-tab

This sub-tab allows you to define one or more unique constraints over the fields defined in the entity. In some target frameworks (e.g. LLBLGen Pro RTL) these unique constraints are used to create extra constructors / filter presets. They're also used to define unique constraints in the Relational Model Data, for the fields mapped by the entity fields in the unique constraints.

To define a unique constraint, click in the top row of the grid and specify a valid name for the unique constraint. The second column is an editor which opens in a separate dialog which allows you to select the field(s) of the unique constraint. Press Ctrl-Enter to add the row to the grid, which adds the unique constraint to the entity definition.

It's not necessary to define a unique constraint for foreign key fields participating in a 1:1 relationship: LLBLGen Pro creates these unique constraints in the Relational Model Data automatically for you. Any unique constraint defined over the same fields is therefore redundant.

To remove a unique constraint from the list of unique constraints of an entity, simply select it and click the 'Remove selected' button at the bottom.

Fields mapped onto related fields sub-tab

Fields mapped onto related fields is a feature which allows you to map a field onto a related field (e.g. in the entity Order the field CompanyName in the related entity Customer to a local field CompanyName) in a related entity. These fields are not real entity fields (they're not mapped onto an element in the target Table / View) and can't participate in database queries; they're a feature which is used in the code generator to produce properties in entity classes which refer to fields in a related entity. This is useful in databinding scenarios where an extra column is sometimes required in a list like control, like a grid, though that column is data from a related entity.

Fields of entities which are related over m:1 or 1:1 relationships are mappable as Fields mapped onto related fields. For example, an Order entity has a related entity Customer. To map the Customer.CompanyName field as a field in Order, simply add it as a Field mapped onto Related Fields in the Entity Editor for Order.

Click the top row in the grid to add a new row and select the field to map from the combo box. Press TAB to advance to the next column to see the field type and specify the name of the field. Eventually select the checkbox for ReadOnly and after that press Ctrl-Enter to add the definition to the entity.

To remove a Field mapped onto a related field, select it using the row header in the grid and click the Remove selected button at the bottom.