We have learned how we can
synchronize persistent and calculated properties, using the @Calculation
annotations, as well as how we can
define logic for multi-user environments. We will now see another method
to define business logic, this time from the database.
If you don't like videos follow the instructions below.
Another alternative to @Calculation
calculated/persistent properties synchronized is the @Formula
is a Hibernate extension to the JPA
standard, that allows you to map a property to a SQL statement. For
example, you can define estimatedProfit
as shown the next code:
@org.hibernate.annotations.Formula("TOTALAMOUNT * 0.10") // The calculation using SQL
@Setter(AccessLevel.NONE) // The setter is not generated, only the getter is needed
BigDecimal estimatedProfit; // A field, as in the persistent property case
This means that when a CommercialDocument
is read from
the database, the estimatedProfit
field will be filled with the
calculation for @Formula
that is done by the database. The user
can filter and ordering by @Formula
properties in list mode, but
they are always read only and are not recalculated in real time in detail
mode. Given they are read only they don't need the setter method, so we
to prevent the setter generation by
Lombok. Moreover, @Formula
properties are database dependent,
because you can use syntax only supported by certain database vendor.
In this lesson you have learned some common ways to add business logic to
your entities. There is no question about the usefulness of calculated
, callback methods, or @Formula
However, we still have many other ways to add logic to your OpenXava
application, which we are going to learn how to use.
In future lessons you will see how to add validation, modify the standard
behavior of the module and add your own business logic, among other ways
to add custom logic to your application.
Download source code of this lesson
Any problem with this lesson? Ask in the forum Everything fine?
Go to Lesson 18