Hades 1.5 released
As you probably already might have noticed, yesterday we released Hades 1.5. Alongside with that the firs 2.0 release candiate sees the light of the day, too. Let me just take some lines to elaborate on the specialty of this release.
Why 1.5?
The first question that might arise is why this release is 1.5 whereas it’s predecessor was 1.1.2. Originally the release was planned as 1.2 but as it introduces some long-ranging features and changes we thought it might be worth indicating that in a larger step of version numbers. As 2.0 is already taken for our JPA 2 upgrade, 1.5 was the choice to go. So what do I mean with “long-ranging”?
Since it’s beginning Hades relied on two major interfaces: GenericDao and Persistable where as especially the latter raised some discussions here and there. Although it is not that of a big deal to implement a 3rd party interface with an entity class it was indeed a hurdle for adoption. So why was it introduced in the first place. GenericDao had the aim to abstract between creation and updates of objects. Although there slight semantic differences this maps to the difference between using EntityManager methods persist(…) and merge(…). To know what to call when save(…) is being called on GenericDao we have to be able to differentiate between a new and an existing entity. As this algorithm might vary from entity to entity, we chose to leave the burdon to decide that to the entity developer by implementing the interface.
Although implementing this interface should not be a big deal actually, we (and the developer community) were not really satisfied with that solutions as the technical infrastructure slightly leaks into the domain abstraction which is somewhat suboptimal kindly speaking. The good news is: as of Hades 1.5 there is no need to implement Persistable anymore. The DAO implementation now uses a reflective approach to lookup the id property of the entity and inspects its value. If it is null, the entity is regarded as new or as already existing otherwise. So that’s the default. If you need to tweak the semantics of new, simply implement Persistable as the algorithm will be simply calling isNew() on you instance then. So in effect, the interface comes into play if explicitly needed and not in any other case.
That’s the big news. Behind that we have a few new features regarding the XML namespace to be used in Spring applications. In case you have multiple EntityManagerFactory beans declared (e.g. in case you work with more than one JPA persistence unit), you can now point the dao-config and dao elements to a specific EMF bean by using entity-manager-factory-ref attribute. Furthermore using exclude-filter and include-filter (probably known from Spring’s context namespace) can be used to tune DAO auto configuration in a more fine grained way. Besides that we have done a general overhaul to the query creation subsystem and now also allow keywords like Between, LessThan and GreaterThan in method names. To round things up we’ve fixed a few minor bugs here and there. For more details read the changelog or the updated reference documentation.
Hades 2.0
Alongside this important step we make another one. JPA 2.0 specification was released a while ago and most existing JPA 1 application wil definately benefit from an upgrade as the new spec version really fills gaps the old one left to workaround for the developers. So what is our approach to the new spec. From a Hades point of view the most intresting part of the new spec is the criteria API as user’s probably will base their custom DAO implementations on it. Furthermore upgrading (Spring) applications demands applications to upgrade to Spring 3.0 and a new major version of the persistence provider of choice we choose to dedicate a 2.0 version of Hades to it.
So the first release candidate builds on top of Spring 3.0.2 as well as Hibernate 3.5, EclipseLink 2.0 as well as OpenJPA 2.0 Beta 3. We will probably wait for our final release until OpenJPA is final, too, but as the majority of users are split between Hibernate and EclipseLink we think that rolling out a release candidate is a good way to get feedback and battle proof the new version. The major change inside Hades 2.0 is that we dropped support of the read-by-example way to access entities. This had to be implemented in a provider specific way so that we could even simplify the codebase in that regard. Furthermore the DAO abstraction is now clearly centered around GenericDao and not blurred with additional interfaces.
So if you can upgrade to Spring 3.0.x and the JPA 2 ready persistence provider already, give Hades 2.0 a try. It should be a drop in replacement in this case. Having that said, it’s probably worth mentioning that even Hades 1.5 can be used with JPA 2.0 but requires more extensive pom configuration on the developer side (as Spring 2.5.6 does not support JPA 2). As you’d end up with a dependency setup similar to the one decalred in 2.0 you’re probably better of just upgrading to Hades 2.0.
