Validation Rules

Introduction

Validation rules are conditions that should be satisfied before an object is committed. If a condition defined by a validation rule is not satisfied when the object is committed, the runtime server generates a validation error.

If the object was committed using a form, this results in a validation message.

If the object was committed in a microflow, this results in an error that can be handled using custom error handling.

In all other cases, a validation error results in a Java exception being thrown.

For example, for entity ‘Customer’ the name and credit need to be filled in at all times, and the expenses cannot be higher than the credit. This is visualized in the domain model editor as follows:

Properties

You can add and edit validation rules for an entity from the entity dialog box.

An example of the validation rule properties is represented in the image below:

Validation rule properties consist of the following sections:

• General
• Rule

General Properties

Attribute

Attribute specifies the attribute to which the validation rule applies. The validation rules apply to attributes of the entity and, if it has a generalization, the attributes of its generalization.

Error Message

Error message defines the message that is displayed to the end-user when the attribute value does not satisfy the condition defined by the validation rule.

Rule Properties

Rule

The rule defines which condition an attribute should satisfy.

Rule Order

Validation rules can be ordered in Studio Pro. The order of the rules determines the order they are applied. If multiple rules are violated, all their error messages will be recorded (in the defined order) and shown in the page. Although the order can be set for all the validation rules in the entity, only the order per attribute will have an impact as all validation rules are executed for all attributes.

The uniqueness validations do not follow the defined order. This validation requires a database query and is executed only when the complete object satisfies all the other validation rules.

Uniqueness Constraint

The uniqueness validation constraint is handled by the database. This enables stateless clustering, a higher number of concurrent users, and applications with a high transaction rate to be handled efficiently.

The following rules are validated in the database:

• Unique rules on entity attributes
• The many side of one-to-many associations, and both sides of one-to-one associations

There are some things you need to consider when applying a uniqueness constraint, especially if you have existing data in the entities to which you are adding the constraint.

Entity Uniqueness

Strings

The uniqueness constraint will take into account the way that the underlying database deals with case sensitivity. For a full discussion of this, see Case-Sensitive Database Behavior.

The uniqueness constraint will also take into account the way that the underlying database deals with string matching. If, for example, two values of a string attribute differ only in having a different number of trailing spaces, some databases will ignore these spaces when deciding if the strings are the same, while others will see them as different.

Existing Entities

When you add a uniqueness constraint to an entity which already contains data, all the existing objects for the affected entity will be checked on deployment for the uniqueness of the attribute. If you have, for example, applied uniqueness validation to an insurance number and there are multiple people with the same insurance number then:

• if you deploy the app from Studio Pro, an error will be shown on deployment
• if you deploy the app from a deployment package (for example in Mendix Cloud), the app will not start and errors will be written to the log

Generalizations

There are limitations on using database uniqueness validation if you are using an entity which is a specialization of another (generalization) entity.

With the database uniqueness validation option enabled, you cannot define the unique validation rule in the specialization entity for attributes which come from the generalization of this entity. If you do this, a consistency error is reported, as in this image:

You can, however, define a unique validation rule for attributes which are added in the specialized entity.

For example, you have two entities:

• a general entity Employee with the attribute EmployeeNumber
• a specialized entity SalesEmployee, based on Employee with the attribute EmailAddress.

Each SalesEmployee will have an EmployeeNumber as that is in the Employee entity. However, you cannot set a validation rule in the SalesEmployee entity to make EmployeeNumber unique.

You can, however, set a validation rule to make EmailAddress unique, as that attribute only appears in the SalesEmployee entity.

You can resolve this issue simply, by moving unique validation rules of these attributes to the generalization entity where the attribute it defined.

Association Uniqueness

Uniqueness constraints also apply to associations. This is done by changing the type of association to have one or both sides of an association set to 1 instead of * (multiple). You may receive an error when you apply a uniqueness constraint to an association which already contains data which is not unique.

Consider the following example:

Initially, the domain model contains a one-to-many association between Address and Person. This means that a Person can have multiple addresses. After some time, the data structure is changed, because you only want to hold one Address per Person. Proper data modeling prescribes changing the association into a one-to-one association. New data will reflect the updated association properly.

Existing association data in the database must also adhere to the updated one-to-one association. This is checked at deployment. If a person has multiple addresses, the model will not deploy, and an error will be given in Studio Pro or in the logs of deployment in the (Mendix) cloud:

We enforce this new stricter association on existing data in order to avoid easily overlooked mistakes that result in returning only a single address per person (where in fact they still have multiple addresses in the database). For example, the Mendix Platform could consistently return the same address each run, but other addresses would be dormant entries in the database.