Persistence in Java

This morning, amid the thousands of other things I'm trying to get done, I decided to formalize my understanding of and opinions on the Java Persistence API (JPA). This is the subject of a new article, Companion Notes on the Java Persistence API and using EclipseLink with Apache Derby at Java Hot Chocolate. I piggy-backed my comments atop an existing tutorial, one of the many fine from among those published by Lars Vogel.

I discuss a few subjects that go beyond the scope of the original tutorial. I note that, while this is a pretty light framework, it's heavier than simply using XStream and the file system which can more easily be done depending on how complex your persistence needs are.

I also discuss the dismal absence of a solution to allow POJOs to evolve respective to this framework and point out that the @Version annotation, whose existence might at first make you think there is such a solution, is really an unrelated, optimistic locking mechanism in JPA.

What's the solution to issuing subsequent updates of your application in which you've made schema changes? There isn't one although I can think of ways to implement one depending on whether you're willing to go outside the framework and test subliminal version references you sprinkle into the POJOs yourself.

It's easy to observe the SQL statements used by JPA via a setting in the metadata file, so no experimentation is necessary to figure out how to go around it. Could you attach triggers to sort some of this out if you wanted to be totally clever (and perhaps a bit obfuscative) in your code to avoid adding too much to your Java corpus?

Each schema class is its own entity and, in the end, each modified class is basically a totally new entity. This is what it comes down to. I've worked on products that couldn't move forward for their schema being so much an anchor around their neck, so I'm interested in having a ready solution next time.