Action Combinations Per Entity Mapping

In the LLBLGen Pro designer, you are able to specify which actions are allowed for a given entity-target database combination. With actions are meant what can be done with an entity: Create, Retrieve, Update and Delete. What is allowed is defined on the mapping of an entity to a given target. Below are the characteristics of this feature.

Supported Frameworks

The following frameworks support all or portions of the feature

  • LLBLGen Pro: complete support
  • NHibernate: Full (Create, Retrieve, Update and Delete) or Retrieve
  • Entity Framework: not supported.
  • Linq to Sql: not supported.

Different actions definable for entities

The following action combinations are definable on entities. They're derived from the CRUD group of actions (Create, Retrieve, Update and Delete). R (retrieve) is always part of the set, because it's impossible to avoid retrieve operations through projections. These action combinations are only in use for operations on tables/views and specifyable on entity mappings to table/view. Typed view, stored procedure and TVF mappings are not using the actions, as they're always Retrieve.

Combinations marked with * require the entity to have at least one field marked as identifying field.

  • CRUD*. The default.
  • CRU*. Disallows deletes. Requires PK for update
  • CR. Disallows updates and deletes. Doesn't require a PK though retrieval of individual entities might be challenging considering no PK means no way to identify a unique row.
  • CRD*. Disallows updates. Requires PK for delete.
  • RU*. Disallows inserts and deletes. Requires PK for update.
  • RD*. Disallows inserts and updates. Requires PK for delete.
  • R. Disallows inserts, updates and deletes. Doesn't require PK, individual entity retrieval might be limited if no pk is present.
  • RUD*. Disallows inserts. Requires PK for update and delete.

An entity requires a PK if at least one mapping of the entity has an action combination defined which requires a PK being present.

Working with action combinations in the designer

The designer works with defaults for the action combinations. These are configurable through the project settings / preferences. The following defaults are configurable:

  • Table target default, through the setting EntityActionCombinationDefaultForTable: CRUD
  • View target default, through the setting EntityActionCombinationDefaultForView: R

They're defined in the preferences and a project derives these settings in a new project.

Action combinations are defined on an entity mapping, so you can specify per entity-target combination an action combination. To do so, open an entity in its editor, go to the field mappings tab and specify the action combinations next to 'Allowed actions'. The default value chosen is the default specified for the target type (table or view) in the project settings.

Table-valued resultset action combinations

The table-valued resultset action combination is defined with the table-valued function, as the mapping is defined there. This also means that an entity can have a different action combination (e.g. CRUD) defined for the mapping on the table and additionally it automatically has R defined for the mapping on the table-valued-function resultset. This means that the actions through the mapping on the table will be Create/Retrieve/Update/Delete, and thus that the entity is read/write.

Defaults when loading a project

When a project is loaded which was saved with a previous version of LLBLGen Pro, there are no action combinations defined on entity mappings, so the default is assumed, as the attribute is an optional attribute (not emitted when the value is equal to 0, the default). This means they'll have the default for entity mappings, which is CRUD.

Inheritance and action combinations

Subtypes always inherit the action combinations of their supertype. This means that it doesn't matter onto which target they're mapped, if the supertype defines R, it's the only action available for subtypes of the supertype.

It's enforced in the designer through validation: It's an error if a subtype has a different action combination on its target for the same DB type than its supertype.