Feature List
Transparent persistence without bytecode processing
Transparent persistence
No required interfaces or base classes for persistent classes, no strange collection classes exposed to application code, support for Java arrays
JavaBeans style properties are persisted
Instance variables are usually considered internal implementation details (property accessors need not be public, however). However, if you prefer, you may persist instance variables directly.
No build-time source or byte code generation / processing
for a fast build procedure (Hibernate uses runtime bytecode generation.)
Support for extensive subset of Java collections API
Map, Set, List, SortedMap, SortedSet, arrays including primitive arrays, Collection
Collection instance management
Collection rows are garbage collected when dereferenced and moved between tables if a collection changes roles
Extensible type system
powerful, innovative model of persistence types - supports user-defined types
- includes built-in support for a rich subset of JDK types including Currency, Locale, BigDecimal, Calendar, etc.
- elegant, performant support for Clob / Blob
Constraint transparency
The application never needs to worry about foreign key constraint violations, even when there are circular references
Automatic Dirty Checking
Modifications to objects associated with a transaction are automatically detected and propagated to the database
Detached object support
Serialized objects may be selectively reassociated with Hibernate, and their state synchronized with the database. You do not need Data Transfer Objects in a multi-tiered architecture!
Object-oriented query language
Powerful object-oriented query language
Queries expressed in a familiar-looking SQL-like language - Table joins expressed as property paths
- Support for SQL functions and operators
- Support for SQL aggregate functions sum, avg, min, max, count
- Support for left|right outer join, full join
- Support for group by, having and order by
- Support for subqueries (on databases with subselects)
- Queries may return tuples of objects or scalar values (projection)
- Support for returning arbitrary data objects via the select new construct
- Dynamic fetch profiles using the fetch keyword
Full support for polymorphic queries
Queries may specify any abstract superclass or interface; from java.lang.Object will return all persistent objects, for example.
New Criteria queries
Alternative object-oriented "query by criteria" API. - full support for association navigation
- runtime fetch profiles (dynamic outer join fetching)
- extensible Criterion framework
- powerful query by Example API
Native SQL queries
Queries may be expressed in the native SQL dialect of your database.
Flexible object / relational mappings
Three different O/R mapping strategies
Three mapping strategies are provided: - table-per-class-hierarchy
- table-per-subclass (normalized mapping)
- table-per-concrete-class
Multiple-objects to single-row mapping
"components" allow for use of fine-grained object composition.
Polymorphic associations
For all three mapping strategies! - Many-to-one: An object reference transparently mapped to a foreign key association
- One-to-many: A collection of objects transparently mapped to a foreign key association
- Many-to-many: A collection of objects transparently mapped to a match table
- One-to-one: An object reference transparently mapped to a primary key, or unique foreign key association
- Ternary: A Map containing and keyed by objects mapped to a ternary association (with or without match table)
Bidirectional associations
for all association styles
Association filtering
Queries upon collection elements
Collections of basic types
Collections of strings, dates, numbers, components, etc
Indexed collections
maps, lists, arrays may be persisted as key-value pairs
Composite Collection Elements
A powerful feature that allows an object oriented representation of: - extra data in many to many association (match) tables
- ternary (and quaternary, etc) associations
Lifecycle objects
Associations may be configured for cascading save / delete. This is our approach to what some projects call "persistence by reachablity" or "dependent objects". Hibernate's approach gives maximimum flexibility and performance
Simple APIs
Simple Core API
for application code
ODMG3-style API
as an alternative to the more expressive native API
Extension APIto allow customization. Plug-in architecture for:
- SQL dialects
- JDBC connection management
- Transaction demarcation
- Primary key generation
- Persistence types
- Persistence strategies (allows integration of classes that are persisted by stored procedures, LDAP, etc)
- Second-level cache providers
Lifecycle callback interface
(optional) gives persistent classes extra control over their persistence lifecycle
Validatable interface
(optional) lets persistent classes check invariants before their state is persisted
Interceptor interface
(optional) allows the application to track audit / history information in a single place
Metadata API
for applications that require access to Hibernate's persistence metadata - it is even possible to manipulate the metamodel programmatically at configuration time
Automatic primary key generation
Multiple synthetic key generation strategiesincluding built-in support for
- identity (autoincrement) columns
- sequences
- UUID algorithm
- HI/LO algorithm
Support for application assigned identifiers
Support for composite keys
Primary keys may span multiple properties of a class, or may be defined in a seperate primary key class
Object/Relational mapping definition
XML mapping documents
- bridge the object / relational "impedence mismatch"
- define the object-relational mapping
- may be used to generate (and export) database table / constraint creation scripts (essential for agile development)
Human-readable format
designed to be edited by hand - the highly readable DTD means no messing around with clunky mapping GUIs.
XDoclet support
allows mappings to be generated from javadoc-style source comments.
HDLCA (Hibernate Dual-Layer Cache Architecture)
Threadsafeness
Each session works with its own distinct set of persistent instances.
Non-blocking data access
Hibernate never forces threads to wait for each other (the database itself might).
Session level cache
A session-level cache resolves circular/shared references and repeated requests for the same instance in a particular session. The cache is completely safe for use in a clustered environment or where Hibernate shares access to the database with other (legacy) applications.
Optional second-level cache
Hibernate features an extremely granular (class or collection role) second-level cache. The actual cache implementation is completely pluggable and supports clustered cache solutions like Tangosol Coherence, SwarmCache, JBoss TreeCache, as well as process-level cache implementations such as EHCache and OSCache. The second-level cache is appropriate for - immutable data
- mutable data in the case of exclusive database access by the Hibernate application
Optional query cache
Query result sets may be selectively cached
Works well with others
Hibernate behaves correctly in an environment where other applications have simultaneous access to the database.
Ultra-high performance
Lazy initialization
- for collections
- for objects (uses runtime bytecode enhancement - no need to implement interfaces)
Outer join fetching
to initialize a graph of associated objects in a single select (for databases with ANSI-style or Oracle-style outerjoins)
Batch fetching
Association roles may be fetched predictively, by batch
Support for optimistic locking with versioning/timestamping
Allows a single conversation (Session) to extend across multiple database connections / transactions without sacrificing transaction isolation. Version numbers / timestamps are updated automatically by Hibernate.
Highly scalable architecture
Designed from the ground up to work in a cluster. Unless the second-level cache is used, there is essentially NO synchronization used in the entire persistence layer. Transaction isolation is guaranteed by the way Hibernate integrates with database / JTA transactions.
High performance
Minimal overhead compared to direct JDBC.
No "special" database tables
Hibernate itself has no persistent state - so theres no extra database tables maintaining locks, mapping data, etc.
SQL generated at system initialization time
rather than at runtime (or buildtime).
(Optional) Internal connection pooling and PreparedStatement caching
J2EE integration
JMX support
Hibernate may be configured and managed via JMX.
Integration with J2EE architecture (optional)
- SessionFactory may be listed in JNDI
- Session is serializable so may be kept by a stateful session bean or in a servlet HttpSession with loadbalancing/failover
- Application server datasource may be used to provide JDBC connections
- Transactions integrate with application server transactions via JTA
New JCA support
Hibernate may now integrate with application servers via JCA.
And more....
Internal logging using Apache commons-logging
may be configured to use log4j or JDK1.4 logging
Programmatic or XML based system configuration
Extensive Test Suite
Automated JUnit tests ensure fixed bugs stay fixed.
Extensive documentation
including full API Javadoc, reference documentation in DocBook format.
Commandline toolset
including database schema export tool for automatic database generation from mapping definitions.
Support for a wide range of databases
including Oracle, DB2, Sybase, MS SQL Server, PostgreSQL, MySQL, HypersonicSQL, Mckoi SQL, SAP DB, Interbase, Pointbase, Progress, FrontBase, Ingres, Informix, Firebird
Free software
The Hibernate License is GNU LGPL. Despite what you may have heard, you certainly may use an LGPL'd library like Hibernate in a commercial closed-source application (providing the application is not a persistence layer!).
|