A JPA implementation, or provider, supplies the persistence behavior behind the JPA specification. It maps Java objects to database columns, reducing the SQL and JDBC result-set copying otherwise needed to persist object graphs. Hibernate is one implementation; Spring Data JPA can sit above it to simplify persistence code further. ORM does not replace every persistence task. section 1.4
Every JPA provider must support a minimum set of Java-to-SQL type conversions. Hibernate supports those standard mappings and adds useful adapters of its own. That distinction matters when a mapping must work with another provider. section 6.3.1
Table 6.1 Java primitive types that map to SQL standard types (view table figure)
Compare the Java primitive and numeric types with their ANSI SQL types; the mapping names are Hibernate-specific. section 6.3.1
Map a decimal and a large value
A BigDecimal property defaults to NUMERIC(19, 2); set @Column precision and scale when schema generation needs different values. For an Item entity with binary image data and a long description, @Lob can mark byte[] and String properties. JDBC Blob and Clob properties are another shown mapping; a Blob can be read through getBinaryStream(). section 6.3.1
The provider also bridges differences between standard SQL types and a particular database. Hibernate uses its configured SQL dialect during schema generation: H2Dialect, for example, maps ANSI NUMERIC to DECIMAL. JDBC provides a partial abstraction of vendor-specific types when Hibernate executes statements such as INSERT and UPDATE. With an existing schema, check the configured dialect’s native type mappings rather than assuming the standard type name appears unchanged. section 6.3.1
Use standard JPA mappings when portability matters. A Hibernate @Type mapping such as yes_no, or unwrapping the JPA entity manager to a Hibernate Session to create a Blob, uses provider-specific behavior rather than the minimum required of every JPA implementation. section 6.3.1
