Multiplatform persistence and ActiveObjects support

[Nathan]

Good news: Databinder has untethered itself from any particular persistence framework, i.e. Hibernate. This is something I'd planned to do all along, but wasn't quite sure how to best go about it or what other persistence I wanted to integrate with. But Daniel Spiewak expressed some interest in getting his ActiveObjects ORM to work with Databinder, and he already had some basic Wicket integration for me to go by; that was enough to make it happen.

My main concern was preserving convenient, direct access to the persistence layer. This is how Databinder has always worked with Hibernate, will always work with Hibernate, and now will work with other persistence technologies. The Databinder toolkit was already split into several modules; now, it's split into a whole lot of modules. "models" and "components" are still there as bases, and what was called "databinder" is now "databinder-app". But to get anything done you have to choose a sub-module, and presently there two: "-hib" and "-ao". So if you want to make an ActiveObjects application, you set "databinder-app-ao" as a dependency and the rest will inherit from there. Your classpath won't be burdened with any Hibernate dependencies or any dead code referring to them.

This is all happening on the trunk and is targeted for 1.2. There will be a 1.1.1 release that has a few bug fixes, tweaks, and enhancements in the nearer future. If you want to try the new ActiveObjects code, the easiest thing is to check out the examples tree from the trunk as the bookmarks example now uses ActiveObjects with Databinder 1.2-SNAPSHOT for persistence.

Code: Select all

svn co svn://databinder.net/examples/trunk examples

Bookmarks is the same old thing as before. I may add some editing functionality to make it less sparse.

For the existing Databinder-Hibernate code, it was necessary to shift around some packages. Although databinder-components was already partitioned with a specific .hibernate pacakge, other modules were not. Now, all Hibernate related Databinder code will go into .hib leaf-packages, and ActiveObjects into .ao . For the most part, running "organize imports" in Eclipse will classes in their new packages. But since this is already a lot of upheaval, I decided to take the opportunity to rename a few classes with the benefit of hindsight (or just, what is now more popular):

DataStaticService -> Databinder (much nicer!)
ICriteriaBuilder -> CriteriaBuilder
IQueryBuilder -> QueryBuilder
IQueryBinder -> QueryBinder
DatabinderProvider -> HibernateProvider (follows HibernateObjectModel, et al.)

The all-static Databinder class will appear only in the various sub "models" modules. So if you want to get your Hibernate session, it's (net.databinder.hib) Databinder.getHibernateSession(), or for ActiveObjects it's (net.databinder.ao) Databinder.getEntityManager(). Assuming your module dependencies are correct, only one "Databinder" class will be visible to the compiler.

Changing the class names in app code is not fun, but I've run thorugh it with the examples and it only took a few minutes. I thought about adding in @Deprecated subclasses and interfaces with the original names so that people's builds would be less broken in migrating, but I'm not sure if it's worth the trouble. (Any thoughts on that?) Migrating Hibernate apps to 1.2 won't be mandatory. In fact it's a good idea to wait on doing it until 1.2 betas at least, in case the API goes through any more big changes. I haven't even split up databinder-auth-components yet, so its code will definitely move around. 1.1.1-SNAPSHOT is a better version to point Databinder-Hibernate apps to, and I would appreciate some testing on that anyway.

But check out ActiveObjects, it's good stuff. And if anyone wants to contribute any more persistence modules, it's not hard to do now that there's a pattern to follow. I'll probably do Carbonado myself for 1.2. You only need to implement the basics; more specialized components like the Hibernate QueryPanel can come later.

Nathan

[ThomasKappler]

Sounds very good. Databinder is going to become the standard ORM solution for Wicket.

[zcox]

I'm a big fan of Wicket and ActiveObjects, and I'll be a big fan of Databinder soon!

Any idea when a 1.2 release might be available with all these ActiveObjects goodies?

[Nathan]

I'm glad there's some interest in it! I would say, don't wait for a release, just check the example tree from the svn command above. When you compile the bookmarks example it will download Databinder 1.2-SNAPSHOT and ActiveObjects 0.8-SNAPSHOT. I'd really like to have another set of eyes look at it, especially if you've been using AO longer than I have (like two weeks!).

The release schedule is that 1.1.1 will be the next release no matter what, probably in a few weeks, and after that I'll start doing betas of 1.2. (AO 0.8 will have to be out and at the Maven repo for that to happen, too.) The final will be a few months off, just because there's a lot of housekeeping to be done (the whole Databinder site will need to be updated... again). And I'd like to debut it with a third persistence tech, though now it doesn't look like that will be Carbonado any more as I've looked into their code and they don't seem to be shooting for Maven-repo distribution any time soon. It will probably be better to go with something that is already safe and sound at the central repository. (Cayenne?)

Nathan

[Nathan]

ActiveObjects 0.8 is out now and I've updated the Databinder 1.2 snapshots to point to it. By the way, there is a template application for AO now:

Code: Select all

svn co svn://databinder.net/templates/trunk/basic-ao

Nathan