Constraints can be modelled on all model types. The following constraint types can be created:
On each of the constraints a threshold value can be set and a supported action that should be executed when the constraint check fails. When a delivery is created one can decide to execute all the constraints, the mandatory constraints, the default constraints or none of the constraints. All the required constraints are checked first. If a constraint violates the record on which the constraint violation is detected will be logged as well as all the violated constraints on this record. When all the constraints are checked the actual number of violations are compared with the thresholds. When the actual number of errors for a constraint exceeds the threshold the delivery will be refused and not processed to the central facts store.
On each reference between two entities in a logical validation model and central facts model you now have the capability of setting the reference as a context filter. With this ability you are capable of determining that "implicit delete detection" should be executed on only a subset (the context filter) of the existing instances of an entity type. For the validation engine you also have the capability that the validation of the set related constraints should only be executed on this subset (the context filter) of existing instance of an entity type.
The new iRefactory web application has numerous new capabilities/enhancements
And had the following new / changed views:
Change | Summary |
---|---|
[IREFACTORY-664] | Make sure only delivered entities can be created for deliverable entities of a logical validation model. An entity is deliverable if it is a baseEntity and has a mapping from a technical staging model. |
[IREFACTORY-132] | When generating the generic data access object types we now first generate an interface and afterwards the implementation. This fixes dependency problems when deploying a generic data access model. |
[IREFACTORY-563] | Generate an error if a reference look-up fails when changing a reference property in a central facts model. |
[IREFACTORY-672] | Performance enhancements in generated triggers. See also [IREFACTORY-673]. |
[IREFACTORY-835] | Remove check on inconsistent load types when creating a delivery on a logical validation model. The user who creates a delivery should determine if inconsistent properties can result in unexpected behaviour. |
[IREFACTORY-859] | Ability to generate the auxiliary reference, attributes and key on a shortcut entity which points to another generic data access model. |
Issue | Summary |
---|---|
[IREFACTORY-675] | An unhandled promise rejection is returned if a metadata import fails. |
[IREFACTORY-666] | Creating a deliveredEntity for which no mapping exists from a technical model results in an error. |
[IREFACTORY-671] | It's not possible to update a fk relationship using it's natural key if it has already a value. |
[IREFACTORY-712] | Error was not reported on relevant record if an error occurred on a post request with a list of records. |
[IREFACTORY-765] | A restful read request fails if the select contains a subtype. |
[IREFACTORY-885] | Delivery: unhandled excretion when no snapshot date provided for delivery and delivered entity. |