Another Hole in Hibernate/JPA

The automatic schema update in Hibernate is great. I remember what a nightmare it was to have to constantly tinker with the structure of the domain model, only to then have to then turn around and dither with the database schema before getting the code out. But it‘s been around now for what, 6 years? at least? Everyone knows once you have a system that has data in it, it stops working. Ask yourself the question, why has this lack not been remedied? There are only a few possibilities:

1. Producer doesn‘t see this as an important requirement.
2. The ‘good enough‘ argument: basically the producer has decided what is there is enough to have satisfied their obligation.
3. Producer believes it is important, but there are so many other things that they have just not found the time for it.

JPA is right up there with JSF in terms of the ambition of their release schedule. When it first hit, the biggest gripe you heard was that it didn‘t include criteria queries. They closed that door now in JPA2, but it took what? 5 or 6 years? Again, X.400 was completely inadequate, but a decade of meetings on X.500 resulted in LDAP, and no one ever using it. Wait, this is sounding kind of familiar? Oh yeah, it‘s reminding me of the recent Rod Johnson article about OSGi.. This is, in fact, the OSGi argument. When species make the wrong gamble and put their energy into things that produce nothing, extinction is their reward, in the ‘open‘ community (ironically peopled with a lot of folks who consider themselves libertarians), the reward is ‘we tried, ok, let‘s move on to the next shiny thing.‘

Ruby has a tool called Migrations, Microsoft does replication (but that doesn't address the deploy time requirements). I have talked to a lot of people and read around about what people are doing in the Java world. It's mostly either some stupid process that reminds you of sunday school homework 'put your db changes into an email/attach to a wiki' or some tool that does a bunch of these things in a semi-automated fashion. Some people still use dbUnit to load their data. We used dbDeploy on a project, which did versioning, albeit in a pretty simplistic way. There is a new (to me) player on this front called FlyWay, which looks interesting, but in reading their brags, I was kind of put off by the one that said ‘native SQL, no XML to maintain.‘ What is the point of Hibernate? To not have database specific code anywhere. One thing I like about Flyway, though, is the idea that I can get an instance to a starting state, then save it as a version and go. Of course, if the next client asks for a different db, that image doesn‘t do me squat.

Final point on this front: blubbering with versions and updating things between instances is going to quickly start to look like seriously crazy nonsense in the age of the Cloud where your mom can get things to move without incurring a team of consultants with caissons and ox carts. Object databases don‘t have this problem because you are not translating things from one language to another. And folks, you are not getting much from this 2 language satyr on this front. Clearly, if you make a balance sheet, this stuff appears in the debt column.

From http://www.jroller.com/robwilliams/entry/another_hole_in_hibernate_jpa