Any reorganization made after setting an attribute as redundant will create a new field in the database. This document describes how GeneXus determines whether the new field may support nulls or not (see Nullable property - Attribute).
Developers cannot manage the nullability of redundant attributes. GeneXus calculates it automatically upon the following criteria:
- For Inferred attributes
- If the original attribute of the redundancy is nullable then the redundant attribute is also nullable.
- Otherwise, the nullability of the redundant attribute will depend on the nullability of the corresponding foreign key.
If the corresponding foreign key may be null (see Example 1 below), then the redundant attribute may also be null. Otherwise, the redundant attribute may not be null.
In this situation, the CustomerName attribute, redundant in the Invoice structure, is defined as allowing nulls.
Customer
{
CustomerID*
CustomerName (Nullable = Yes)
}
Invoice
{
InvoiceId*
CustomerId* (Nullable = No)
CustomerName (Redundant)
}
Even when CustomerName does not allow nulls in Customer, CustomerId does allow them in Invoice. It is for this reason that CustomerName must allow nulls in Invoice.
Customer
{
CustomerID*
CustomerName (Nullable = No)
}
Invoice
{
InvoiceId*
CustomerId* (Nullable = Yes)
CustomerName (Redundant)
}
In this example, redundant formulas CustomerTotal and InvoiceDetailAmount do not allow nulls in the corresponding tables.
Customer
{
CustomerID*
CustomerName
CustomerTotal=Sum(InvoiceTotal) (Redundant)
}
Invoice
{
InvoiceId*
CustomerId*
CustomerName
...
{
InvoiceDetailId*
...
InvoiceDetailAmmount=InvoiceDetailQuantity * ProductPrice (Redundant)
}
InvoiceTotal=sum( InvoiceDetailAmmount)
}