openxava / documentation / Lesson 17: Logic from the database

Course: 1. Getting started | 2. Basic domain model (1) | 3. Basic domain model (2) | 4. Refining the user interface | 5. Agile development6. Mapped superclass inheritance | 7. Entity inheritance | 8. View inheritance | 9. Java properties | 10. Calculated properties | 11. @DefaultValueCalculator in collections | 12. @Calculation and collections totals | 13. @DefaultValueCalculator from file | 14. Manual schema evolution | 15. Multi user default value calculation | 16. Synchronize persistent and computed properties | 17. Logic from database | 18. Validating with @EntityValidator 19. Validation alternatives  | 20. Validation on remove  21. Custom Bean Validation annotation  | 22. REST service call from validation  | 23. Attributes in annotations  | 24. Refining the standard behavior | 25. Behavior & business logic | 26. References & collections | A. Architecture & philosophy | B. Java Persistence API | C. Annotations | D. Automated testing

Table of contents

Lesson 17: Logic from the database
Database logic (@Formula)
We have learned how we can synchronize persistent and calculated properties, using the @Calculation and @DefaultValueCalculator 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.

Database logic (@Formula)

Another alternative to @Calculation or having calculated/persistent properties synchronized is the @Formula annotation. @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 with @Formula in CommercialDocument 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 use @Setter(AccessLevel.NONE) 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 properties, @Calculation, 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