Thinking about wiki backends

Lately I've been thinking a lot about wiki backends. Others have thought about new weblog backends. From my point of view, most wikis in the Java world use ORM oder mostly JDBC backends. Currently there is a lot of buzz about JPA. JPA is a great standard to unify ORM apis and would enable users change the ORM solution in their wiki with a drop in replacement. Others do this with their app server successfully.

But for wikis the JPA abstraction level is still to low level. Much better suited is JSR 170 aka Content Repository for Java (JCR) 1.0 and the upcoming next version. Applications can specify their needs for content storage on a high abstraction level with metadataed (= property) chunks of content. There can be title, content, attachments and author properties (JCR tutorial). If all wikis share the same property namespace and the same standard markup, users could change their wiki implementations without the need to migrate data. Just start the new engine. Users could even run two wiki engines for different needs on the same content backend.

Imagine a JCR implementation (Jackrabbit please!) which uses JPA. Best of two worlds: High abstraction and content portability and plugable ORM and JCR implementations.

That were just some of my thoughts on wiki backends 2006 style.

Moving away from Hibernate

One reason for me to move to JPA is to move away from Hibernate. Since being part of the JBoss ecosphere, Hibernate forums adapted to the spirit of the JBoss forums. There are other examples, but for one example see here. They like to be part of JBoss and not be part of JBoss just as it is most useful for them. Not when it's useful to their users. With wrong information for their users,

"Hibernate does not use JBoss. JBoss uses hibernate." -tenwit

Hibernate JPA uses the JBoss common jar, so clearly Hibernate uses JBoss code. The JBoss common jar bothered me too when using JBoss (?) / Hibernate (?) JPA. Otherwise it's obviously a nice product.

Update: Some time after this post the thread on the Hibernate forum got activated again and a JBoss employee "debunked" Tenwit: "that code is most likely used by Hibernate Annotations and thus it is relevant." Thanks.

JPA Spring problems? Criterias?

JPA with Spring works fine. The only problem is the generateDdl attribute for the EntityManager. This makes the EM generate SQL DDL statements to create tables. But if there are already tables in the database, they are dropped and created new. Is there a configuration to generate tables when there are none, but keep them when there are already tables?

The other thing about Spring JPA is that EQL queries are a step back from a criteria based API. Hibernate, Grails, all use safer and typed query builders for querying databases. Hope Spring adds JPAUtils for a criteria based API for JPA.