JPA Criteria spatial extension

[beikov]

Hibernate Spatial was not yet adapted in 6.0 and I would like to propose we try to move some code from the spatial module into hibernate-core. IMO the only reason for having a separate module is to avoid a dependency on the geometry type libraries, but we could move everything that is unrelated to the types up into hibernate-core.

My idea is that hibernate-spatial in 6.0 will only contain:

• Type descriptors for the geometry types
• JPA Criteria extensions

The JPA Criteria extensions could be made accessible through the existing JTSSpatialPredicates class with it's static methods, or through a subclass SpatialCriteriaBuilder which could be created/accessed through a unwrap method on HibernateCriteriaBuilder. This could look like the following:

SpatialCriteriaBuilder cb = session.getCriteriaBuilder().unwrap(SpatialCriteriaBuilder.class);

The spatial criteria builder, and maybe other implementions (search, ogm), would be added to the HibernateCriteriaBuilder through a service loader contract. This could look like the following:

public SqmCriteriaNodeBuilder() {
    ...
    for (CriteriaBuilderExtension extension : ServiceLoader.load( CriteriaBuilderExtension.class )) {
        HibernateCriteriaBuilder builder = extension.extend( this );
        extension.getRegistrationKeys().forEach( key -> extensions.put( key, builder ) );
    }
}

public <T> T unwrap(Class<T> clazz) {
    return (T) extensions.get( clazz );
}

[sebersole]

This should really be up to, or at least as significant imput from, Karel. I started this discussion with him yesterday on Zulip.

[beikov]

Can we get some feedback here @maesenka?

[maesenka]

For me this is OK, with the caveat that we need to distinguish between JTSSpatialCriteriaBuilder and GeolatteSpatialCriteriaBuilder. The type of CriteriaBuilder to unwrap is tied to the Geometry library used in the model.

The previous discussion on Hibernate Spatial were already in the same spirit (i.e. to move as much as possible into hibernate-core)

[beikov]

What do you think about having just a single API and "misusing" the model type of the expressions via a type variable to avoid listing the concrete geometry type? Something like this:

public <T> Predicate within(Expression<T> geometry1, Expression<T> geometry2) {...}
public <T> Predicate within(Expression<T> geometry1, T geometry2) {...}

This could work as long as the user model types are of the type Geometry or if it is a subtype, the user only uses the same Java type i.e.

@Entity
public class Location {
    Point point;
    Geometry geometry;
}

// Needs a cast to Point because fromWkt returns Geometry
cb.within(root.get(Location_.point), (Point) Wkt.fromWkt("....", Wkt.Dialect.SFA_1_1_0));
// Works fine
cb.within(root.get(Location_.geometry), Wkt.fromWkt("....", Wkt.Dialect.SFA_1_1_0));
// Not sure if Javac really needs the cast in these two cases
cb.within(root.get(Location_.geometry), (Geometry) root.get(Location_.point));
cb.within((Geometry) root.get(Location_.point), root.get(Location_.geometry));

It would be a bit less compile time safe as we will only check at runtime that the passed arguments are of the proper geometry type, but at least the API would be the same for both models.

[maesenka]

The most likely use for the within() predicate is to test whether a Point is within some Polygon. In such caes we will have Expression<Point> and Expression<Polygon> for the first, resp. second argument. That is why I don't think that the requirement that "the user only uses the same Java type" would be acceptable.

I would also like to let users use the most specific geometry types at the call site, rather then force them to cast to the most general type, i.e. Geometry. But this will be the consequence of the API that you propose.

Given the above considerations, I think having two separate CriteriaBuilder implementations is the lesser of two evils.

[beikov]

As discussed on Zulip, then let's go with something like this:

interface SpatialCriteriaBuilder<T> {
public Predicate within(Expression<? extends T> geometry1, Expression<? extends T> geometry2) {...}
public Predicate within(Expression<? extends T> geometry1, T geometry2) {...}
...
}

with 2 subtypes GeolatteSpatialCriteriaBuilder implements SpatialCriteriaBuilder<Geometry> and JTSSpatialCriteriaBuilder implements SpatialCriteriaBuilder<Geometry>.