In the previous lesson we learned
how to define default properties for development in multi-user
environments, using
JPA callbacks. We will now see how to
synchronize both computed and persistent properties.
If you don't like videos follow
the instructions below.
Synchronizing
persistent and calculated properties
As we already have learned, calculated properties do not allow to filter
or ordering in list, so we prefer persistent properties with
@Calculation.
However,
@Calculation properties are only valid for simple
arithmetic calculations. When you need loops, condition, read from
database, connect to external services, or some complex logic,
@Calculation
is not enough. For these cases you need to write the logic with Java, in
the getter. But, how we can do this and at the same time keep the ordering
and filtering in list? Simple, you can use two properties, one calculated
and one persistent, and synchronize both using JPA callback methods.
You're going to learn how to do it in this section.
Let's add a new property to Order
entity called estimatedDeliveryDays:
@Depends("date")
public int getEstimatedDeliveryDays() {
if (getDate().getDayOfYear() < 15) {
return 20 - getDate().getDayOfYear();
}
if (getDate().getDayOfWeek() == DayOfWeek.SUNDAY) return 2;
if (getDate().getDayOfWeek() == DayOfWeek.SATURDAY) return 3;
return 1;
}
This is a pure calculated
property, a getter with Java logic. It calculates the estimated delivery
days using date as source. This case cannot be solved with @Calculation
that only supports basic arithmetic calculations.
We also have to add estimatedDeliveryDays
to the default @View declaration in Order code:
@View(extendsView="super.DEFAULT",
members=
"estimatedDeliveryDays," + // ADD THIS LINE
"invoice { invoice }"
)
...
public class Order extends CommercialDocument {
The result is this:
The value is recalculated each
time the date changes in the user interface thanks to the @Depends("date")
in estimatedDeliveryDays. This is all very nice, but when you go
to list mode you cannot order or filter by estimated delivery days. To
solve this problem we add a second property, this time a persistent one.
Add the next code to your Order entity:
@Column(columnDefinition="INTEGER DEFAULT 1")
int deliveryDays;
Note as we have used @Column(columnDefinition="INTEGER
DEFAULT 1"), with this trick when OpenXava creates the column uses
"INTEGER DEFAULT 1" as column definition, thus the new column has 1 as
default value instead of null, and we avoid an ugly error with our int
property. Yes, in many cases @Column(columnDefinition=) is an
alternative to do an UPDATE over the table (as we did in "Manual schema
evolution" section), although has the problem that is database dependent.
Anyways, this columnDefinition dissertation is tangential to our
calculated/persistent synchronization issue, @Column is not
required at all, it's just convenient for this int property.
This new deliveryDays
property will contain the same value as estimatedDeliveryDays,
but deliveryDays will be persistent with its
corresponding column in the database. The tricky issue here is to have the
deliveryDays property synchronized. We will use the JPA callback
methods in Order to achieve this. It's enough to assign the
value of estimatedDeliveryDays to deliveryDays each time
that a new Order is created (@PrePersist) or updated (@PreUpdate).
Add a new
recalculateDeliveryDays()
method to
Order entity annotated with
@PrePersist and
@PreUpdate,
thus:
@PrePersist @PreUpdate
private void recalculateDeliveryDays() {
setDeliveryDays(getEstimatedDeliveryDays());
}
Basically, the
recalculateDeliveryDays() method is called
every time an
Order entity is registered in the database for the
first time and when the order is updated.
You can try the Order
module with this code, and you will see how when a order is created or
modified, the column in the database for deliveryDays is
correctly updated after saving, ready to be used in massive processing and
available for ordering and filter in list.
Summary
In this lesson you have learned how easy it is to use JPA callback methods
to define logic at different specific moments in the life cycle of an
entity, allowing us to synchronize persistent and calculated properties
when modifying an existing entity, or saving an entity for the first time.
