In Hibernate, what does the @Formula annotation on an entity property do, where does its value come from, and what are its limitations?

## What it is `org.hibernate.annotations.Formula` is Hibernate-specific, not part of JPA. On a field or getter it declares: *this property has no column; compute it with this SQL expression*. Hibernate injects the expression into the select list of the entity's SELECT, aliases it, and populates the field from the result set. The fragment is **native SQL**, not JPQL. Unqualified column names are resolved against the entity's own table, so `@Formula("unit_price * quantity")` works on the row being loaded. Because it is real SQL you can also write a correlated subquery — `(select count(*) from order_line l where l.order_id = id)` — or call vendor functions. ## What Hibernate does with it On `em.find(Order.class, 1L)` Hibernate emits roughly: ``` select o.id, o.status, (unit_price * quantity) as formula0 from orders o where o.id = ? ``` The property participates in the loaded state like any other, so it is readable in Java and usable in HQL/JPQL and Criteria as a path — Hibernate substitutes the expression wherever the property is referenced, which means `where o.total > 100` becomes `where (unit_price * quantity) > 100`. ## Read-only, and what that implies The property is excluded from the INSERT and UPDATE statements Hibernate generates, and it is not part of dirty checking. Setting it in Java has no persistent effect at all, so the setter (if any) is a lie — expose it as a getter over a private field and never write to it. Because the value is produced by the database at *load* time, it is a snapshot. If you load an order, change a line quantity, and flush, the formula field in memory is not recalculated: Hibernate would have to re-SELECT the row to know the new value. `EntityManager.refresh(order)` does exactly that; so does evicting and reloading. This staleness surprises people who expect it to behave like a Java getter. ## Costs The expression runs for every row returned by every query that loads the entity, and for every lazy proxy that gets initialised. A scalar arithmetic expression is essentially free. A correlated subquery is not: fetching 500 entities runs the subquery 500 times inside one statement, and the database usually cannot use an index for it the way it could for a plain column. Filtering or sorting on a formula generally means recomputing it for every candidate row, because there is no column to index (unless the database supports an expression index whose expression matches exactly). A second cost is portability and tooling: the fragment bypasses the dialect, so vendor functions, quoting and casting rules leak into the mapping. Column-name resolution also collides with naming strategies — the formula must use the *physical* column names, not the Java property names. ## When to use it, and the alternatives Use `@Formula` for small, cheap, read-only derivations that you want visible on the entity without a schema change: a concatenated display name, a simple arithmetic total, a boolean flag like `(end_date < current_date)`. Reach for something else when the value is expensive or heavily queried: - A **stored generated column** (`GENERATED ALWAYS AS (...) STORED`) computes at write time, can be indexed, and applies to every writer; map it read-only with Hibernate's `@Generated`. - A **database view** mapped as an immutable entity is better for reporting shapes that join several tables. - A **plain Java method** on the entity is better when nothing needs to filter or sort on the value in SQL. A related annotation is `@JoinFormula`, which does the same trick for an association's join condition. Both are power tools: they make the mapping do things JPA cannot express, at the price of vendor SQL inside your entity.