ORMs (Object-Relational Mapping)

What Is an ORM — and Why Does It Exist?

An Object-Relational Mapper is a library that translates between Java objects and relational rows, so application code manipulates Product and Order instances instead of hand-writing a ResultSet-to-object mapping for every query. It exists because objects and tables model data in fundamentally incompatible ways — objects have identity, inheritance, and object references; tables have primary keys, flat columns, and foreign keys. This gap is called the object-relational impedance mismatch, and every ORM exists solely to bridge it.

// WITHOUT an ORM — every query hand-maps ResultSet columns to fields
public Product findById(long id) {
    String sql = "SELECT id, name, price, category_id FROM products WHERE id = ?";

    try (Connection conn = dataSource.getConnection();
         PreparedStatement stmt = conn.prepareStatement(sql)) {

        stmt.setLong(1, id);
        try (ResultSet rs = stmt.executeQuery()) {
            if (rs.next()) {
                Product product = new Product();
                product.setId(rs.getLong("id"));
                product.setName(rs.getString("name"));
                product.setPrice(rs.getBigDecimal("price"));
                // Need the category too? That's a second query, written by hand,
                // and a decision about whether to run it now or defer it.
                return product;
            }
        }
    } catch (SQLException e) {
        throw new DataAccessException("Failed to load product " + id, e);
    }
    return null;
}

// WITH an ORM (JPA / Hibernate) — the mapping is declared once on the
// entity; every query after that reuses it automatically.
public Product findById(long id) {
    return entityManager.find(Product.class, id);
}

The Object-Relational Impedance Mismatch

Five specific mismatches recur in every ORM's design, and understanding them explains why ORMs need annotations like @OneToMany or @Inheritance at all — they aren't arbitrary API surface, they each solve one of these concrete mismatches.

Four Categories, Not One Tool — Where Each Actually Fits

"ORM" is often used loosely to mean any Java-to-SQL abstraction, but the four real categories make fundamentally different trade-offs between how much SQL you write and how much control you keep over it.

// The same query, three ways — same e-commerce Product table

// 1. FULL ORM (JPA / Hibernate) — declare the mapping once, query with objects
@Entity
public class Product {
    @Id @GeneratedValue private Long id;
    private String name;
    private BigDecimal price;
    @ManyToOne private Category category;
}
Product product = em.find(Product.class, 1L);   // no SQL written

// 2. SQL MAPPER (MyBatis) — you write the SQL, it maps the result
// mapper.xml: <select id="findById" resultType="Product">
//   SELECT * FROM products WHERE id = #{id}
// </select>
Product product = productMapper.findById(1L);   // your SQL, mapped result

// 3. SQL BUILDER (jOOQ) — type-safe SQL, validated against the schema at compile time
Result<Record> result = create
    .select(PRODUCTS.NAME, CATEGORIES.NAME)
    .from(PRODUCTS)
    .join(CATEGORIES).on(PRODUCTS.CATEGORY_ID.eq(CATEGORIES.ID))
    .where(PRODUCTS.ID.eq(1L))
    .fetch();

Hibernate — Transparent Persistence, Dirty Checking, Caching

Hibernate is the JPA provider used in the overwhelming majority of Spring Boot applications (Spring Data JPA delegates to it by default). Four mechanisms account for most of what makes it feel "automatic":

Automatic dirty checking

Product product = em.find(Product.class, 1L);
product.setPrice(new BigDecimal("24.90"));
// No explicit save() call — Hibernate compares the entity's current
// field values against the snapshot it took when the entity was loaded.
tx.commit();
// → UPDATE products SET price = 24.90 WHERE id = 1
//   issued automatically at flush time, only for the fields that changed

Identity within the persistence context (first-level cache)

Product p1 = em.find(Product.class, 1L);   // hits the database
Product p2 = em.find(Product.class, 1L);   // same EntityManager → returned from the L1 cache, no query
System.out.println(p1 == p2);   // true — literally the same Java instance
// This identity guarantee holds only within one EntityManager/session.
// A different request, a different EntityManager, gets a different instance.

Lazy loading and HQL

@OneToMany(mappedBy = "order", fetch = FetchType.LAZY)
private List<OrderItem> items;

Order order = em.find(Order.class, 1L);   // items NOT loaded yet
order.getItems().size();               // NOW the SELECT for items runs

// HQL/JPQL: object-oriented query language, operates on entity names and
// fields, not table and column names
List<Product> discounted = em.createQuery(
        "SELECT p FROM Product p WHERE p.price < :maxPrice", Product.class)
    .setParameter("maxPrice", new BigDecimal("20"))
    .getResultList();

MyBatis — SQL-Centric Mapping

MyBatis inverts Hibernate's default posture: you write the SQL, and the framework's only job is mapping the result set onto your objects. Reach for it when the SQL is complex enough that fighting an ORM to produce it costs more than writing it directly — heavy reporting queries, stored-procedure-driven systems, or a legacy schema an ORM's conventions don't fit cleanly.

<!-- OrderMapper.xml -->
<mapper namespace="com.shop.mapper.OrderMapper">

    <resultMap id="orderResultMap" type="Order">
        <id property="id" column="order_id"/>
        <result property="status" column="status"/>
        <association property="customer" javaType="Customer">
            <id property="id" column="customer_id"/>
            <result property="email" column="customer_email"/>
        </association>
    </resultMap>

    <!-- Dynamic SQL: build the WHERE clause conditionally, still as real SQL -->
    <select id="search" resultMap="orderResultMap">
        SELECT o.id AS order_id, o.status, c.id AS customer_id, c.email AS customer_email
        FROM orders o JOIN customers c ON c.id = o.customer_id
        <where>
            <if test="status != null"> AND o.status = #{status} </if>
            <if test="minTotal != null"> AND o.total >= #{minTotal} </if>
        </where>
    </select>

</mapper>

public interface OrderMapper {
    Order findById(long id);
    List<Order> search(OrderSearchCriteria criteria);

    // Annotation form for the simple cases — XML for anything with joins or dynamic conditions
    @Select("SELECT * FROM orders WHERE id = #{id}")
    Order findByIdSimple(long id);
}

jOOQ — Type-Safe SQL Generated From Your Schema

jOOQ generates Java classes from your actual database schema at build time, then lets you compose SQL through a fluent API built on those generated classes. A typo in a table or column name fails the build, not a request in production — the opposite failure mode from JPQL, where a typo compiles fine and only surfaces the first time that query path executes.

// JPQL — a typo compiles, and only fails the first time this line executes
em.createQuery("SELECT p FROM Prodcut p");   // runtime exception

// jOOQ — the same typo doesn't compile, because PRODCUT doesn't exist
// as a generated constant
create.selectFrom(PRODCUT);   // compile error

import static org.jooq.impl.DSL.*;
import static com.shop.generated.Tables.*;   // generated from the schema

public class ProductRepository {

    private final DSLContext create;

    public List<Product> findByPriceRange(BigDecimal min, BigDecimal max) {
        return create
            .selectFrom(PRODUCTS)
            .where(PRODUCTS.PRICE.between(min, max))
            .orderBy(PRODUCTS.PRICE.desc())
            .fetchInto(Product.class);
    }

    // Aggregate reporting query — exactly the kind of query that fights an ORM
    public Map<String, BigDecimal> avgPriceByCategory() {
        return create
            .select(CATEGORIES.NAME, avg(PRODUCTS.PRICE))
            .from(PRODUCTS)
            .join(CATEGORIES).on(PRODUCTS.CATEGORY_ID.eq(CATEGORIES.ID))
            .groupBy(CATEGORIES.NAME)
            .fetchMap(CATEGORIES.NAME, avg(PRODUCTS.PRICE));
    }

    // Dynamic query — conditions composed at runtime, still fully type-checked
    public List<Product> search(ProductSearchCriteria criteria) {
        SelectConditionStep<Record> query = create.selectFrom(PRODUCTS).where(trueCondition());

        if (criteria.getName() != null) {
            query = query.and(PRODUCTS.NAME.containsIgnoreCase(criteria.getName()));
        }
        if (criteria.getCategoryId() != null) {
            query = query.and(PRODUCTS.CATEGORY_ID.eq(criteria.getCategoryId()));
        }
        return query.fetchInto(Product.class);
    }
}

Choosing the Right Approach

Hybrid: pick per query, not per project

These tools are not mutually exclusive within one codebase. A common, genuinely good production pattern: JPA repositories for the CRUD that makes up 90% of the code, and jOOQ dropped in specifically for the reporting queries that would otherwise become an unmaintainable native @Query string.

// Spring Data JPA handles ordinary CRUD
public interface ProductRepository extends JpaRepository<Product, Long> {
    List<Product> findByCategoryId(Long categoryId);
}

// jOOQ handles the reporting query that JPQL would make unreadable
@Service
public class CatalogReportService {

    private final DSLContext dsl;   // jOOQ, same datasource as JPA

    public List<CategoryPricingReport> generatePricingReport() {
        return dsl
            .select(
                CATEGORIES.NAME,
                count(PRODUCTS.ID).as("product_count"),
                avg(PRODUCTS.PRICE).as("avg_price")
            )
            .from(PRODUCTS)
            .join(CATEGORIES).on(PRODUCTS.CATEGORY_ID.eq(CATEGORIES.ID))
            .groupBy(CATEGORIES.NAME)
            .having(count(PRODUCTS.ID).gt(5))
            .orderBy(avg(PRODUCTS.PRICE).desc())
            .fetchInto(CategoryPricingReport.class);
    }
}

Best Practices and Common Pitfalls

Interview Questions