Summary
In a recent blog post, Hibernate project lead Steve Ebersole introduces two new ID generator classes available in Hibernate 3.2.3, and describes the key problems with ID and sequence generation in O/R mapping.
Advertisement
Most object-relational mapping frameworks aim to provide a high degree of database portability: It should be possible to build applications on top of an O/R mapping framework such that the application can work with any underlying database supporting a required set of features.
In addition to differences in database syntax, among the more interesting aspects of database portability is sequence and ID generation: While most databases provide some built-in ID and sequence-generating capability, databases differ in their ID generation implementation.
To build portable applications, Hibernate, like other O/R mapping tools, provides a set of classes that encapsulate ID and sequence generation strategies. In a recent blog post, New (3.2.3) Hibernate identifier generator, Hibernate project lead Steve Ebersole introduces two new ID generators available in Hibernate 3.2.3:
Using a synthetic identifier generation strategy while eyeing portability really comes down to wanting the capabilities that a sequence provides even though the database may not support sequences.... Generally speaking an Object/Relational Mapping technology will prefer identifier generation strategies where the identifier value can be retrieved before performing (and without having to actually perform) the insert statement; this is certainly true of Hibernate and other "transactional write behind" technologies.
The two new ID generators are:
org.hibernate.id.enhanced.SequenceStyleGenerator
On databases which support SEQUENCEs, SequenceStyleGenerator will in fact use a SEQUNCE as the value generator; for those database which do not support SEQUENCEs, it will instead use a single-row table as the value generator, but with the same exact charecteristics as a SEQUENCE value generator (namely it deals with the "sequence table" in a separate transaction at all times).
org.hibernate.id.enhanced.TableGenerator
Uses a multi-row table where the rows are keyed by a (configurable) "sequence_name" column... It grew out of the older org.hibernate.id.MultipleHiLoPerTableGenerator and uses basically the same table structure. However, while MultipleHiLoPerTableGenerator inherently applies a hi-lo algorithm to the value generation, this new TableGenerator was added to be able to take advantage of the pluggable optimizers.
Each ID generator can consume several parameters, including an optimizer:
The role of the optimizer is to limit the number of times we actually need to hit the database in order to determine the "next identifier value". The exact effect of initial_value and increment_size somewhat depend on the optimizer chosen.
In the rest of his blog post, Ebersole describes the differences in the implementation of the two new ID generators.
As Ebersole's blog post shows, ID generation, seemingly a simple task, is the result of cooperation between the application, or some middleware, and the database. For a different take, describing object identifiers that can be generated entirely within an application, you may want to read Joe Celko's comments on using globally unique IDs as database keys.
What criteria do you follow to determine the right ID generator strategy for an application?
Before answering that question, I would have to answer another question: do we really need an O/R mapping layer?
In all the projects I was involved in the last few years, we always started with "let's use Hibernate", but in the end we never did...it was always simpler to use JDBC directly.
My experience is similar. The benefits of an OR mapper are very questionable: - for simple projects, you can do pretty much w/o OR mapper, no extra complexity, no learning curve for specific ORM product. - for bigger and more complex projects you often has additional non functional requirements for performance and scalability, which are often not possible with ORM.
What is interesting I found that this problem is not with ORM in particular, but in every complex framework. Frameworks are not suitable for small projects, as they are often complex (learning curve, dependencies...). For bigger projects they introduce dependencies and performance hit, which are most often not tolerable.
ORM, as other frameworks (including EJB ;)) has very narrow software project/problem applicability. There are much more efficient ways for abstracting thinks, like good design and DSLs, for example.
No offense, but I think both of you are expressing opinions that have been completely discredited in recent years. It is now widely recognized that direct use of JDBC should be the exception, not the norm.
Hibernate would be considered the 'default' choice for Java database access at this point in time. The overhead is low enough that experienced users would consider it at least as productive as JDBC. I suspect Achilleas' team resort to 'raw' JDBC because it is more familiar to them, not because it is actually 'better' in an objective sense.
And Mileta's assertion that frameworks are not suitable for bigger projects because "they introduce dependencies and performance hit, which are most often not tolerable" is just factually incorrect.
Spring is, IMO, well on its way to becoming the default programming model for Java-based enterprise applications. Completely non-intrusive. Simplifies ORM usage. Enforces many 'best practices'. Even greatly simplifies JDBC usage when that becomes necessary. And no one seriously claims that Spring apps are inherently poor performing.
I suspect is what people like Mileta really dislike about frameworks is lack of personal freedom. They want to design everything themselves, even though 're-inventing the wheel' is a tremendous waste of their company's time and resources. It's more fun for them. Using somebody else's framework would be a blow to their ego, too. "I can do better than that!" they declare. Which is really just an excuse so they don't have to standardize and can 'play around' with their own designs all they want.
I second that Chris. I use ORM for both large and small. I can crank out an app much faster and also make one more maintainable. Optimization is easier too.
Previous Topic
