Thanks for your feedback so far. By now, I've converted my complete entity
model from Hibernate to JPA (on a trial branch...) and the experience has
been rather painless. Finally, certain things that never worked with
Hibernate are not a problem any longer. I discovered inconsistencies in my
model that Hibernate would let pass, and so far just one potential bug in
OpenJPA regarding @MapKey.
Anyway, converting all the geospatial extensions will be the hardest part.
For sure, this is not part of the JPA spec, but still I need to solve this
somehow.
I'm currently using an extension named Hibernate Spatial (which is not
_from_ Hibernate/RedHat, but _for_ Hibernate), and from what I've seen in
their sources, Hibernate offers you hooks to register functions at SQL and
even HQL/JPQL level. This is what Hibernate Spatial uses internally to make
things rather easy for their users.
Example:
jpql = "select p from GeoPosition p where within(p.point, :filter) =
true";
query = em.createQuery(jpql, GeoPosition.class);
Geometry filter = factory.toGeometry(new Envelope(9.9, 10.1, 53.4,
53.6));
CustomType geomType = new CustomType(GeometryUserType.class, null);
Query hibernateQuery =
query.unwrap(QueryImpl.class).getHibernateQuery();
hibernateQuery.setParameter("filter", filter, geomType);
positions = query.getResultList();
The corresponding entity is
@Entity
public class GeoPosition {
@Id
private long id;
@Type(type = "org.hibernatespatial.GeometryUserType")
private Point point;
}
"Point" is a Geometry type from the JTS topology suite, not from PostGIS.
I think you get the idea. This is all rather nifty, and most of the work is
hidden in Hibernate Spatial, but to be fair on Hibernate, this would not
have been possible without suitable extension points in Hibernate Core.
Now with OpenJPA, I understand it should be rather easy to write the
equivalent of a Hibernate UserType to persist JTS Geometry fields. Of course
I could always fall back to a native SQL query, which would not hurt too
much in the above example, but sooner or later I will also need a
combination of joins along associations with geospatial filters, so this is
more of a workaround than a solution: you really want to be able to use
spatial predicates at JPQL level.
@Jerry: Can you explain a bit more about the Criteria API approach? I'm not
bent on JQPL if there is an easier way of representing spatial predicates as
criteria, but I don't see how to do it...
@Kevin: Yes, "impossible is nothing", but after my first week with OpenJPA,
I wouldn't really like to start hacking the parser ;-) It seems in Hibernate
the operators are not all hard-coded in the parser, they are just
identifiers, and Hibernate extensions are able to plug in additional
handlers for additional operators.
Thanks for pointing me to the data dictionary - yes, I'll take a look at
that.
Best regards,
Harald
--
View this message in context:
http://openjpa.208410.n2.nabble.com/OpenJPA-and-PostGIS-or-other-spatial-extensions-tp5302323p5311362.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
