[hibernate-dev] Merging hibernate spatial Dialects with the core ones

[Gunnar Morling]

One thing to keep in mind is that the module system of Java 9 ("Jigsaw")
doesn't support a notion of optional module dependences.

So if this is meant to remain an "optional feature" (i.e. Geo-specific
libraries are not required at runtime when not using the spatial stuff), it
should remain a separate artifact - this is, should we plan to make
Hibernate ORM JARs Jigsaw modules at some point.

--Gunnar


2016-06-28 15:22 GMT+02:00 Karel Maesen <karel at geovise.com>:

> It makes sense for some Dialects such as those for MySQL and MS SQL Server.
> Less so for Postgresql and Oracle Spatial because here the spatial
> capabilities need to be installed and configured separately (and even have
> versioning separate from the main database engine).
>
> I would favour an approach, close to what Sanne is suggesting, where the
> spatial capability (Incl. Types) is injected into the Dialect during
> Dialect construction based on some explicit configuration. In that way the
> relation between Dialect and the spatial capability mirrors the relation
> between database engine and spatial capability (if any).
>
> Regards,
>
> Karel
>
> PS: I'm leaving tomorrow on holiday for a couple of weeks so I won't be
> able to resume the exchange before July 20.
>
> On Mon, Jun 27, 2016 at 3:53 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > They have not been "merged" in the same way we merged
> > hibernate-entitymanager into hibernate-core.    So at the moment using
> > hibernate-core e.g. does not require geolatte to be present.  geolatte is
> > only required if using hibernate-spatial (isolated transitive dep).
> >
> > Karel, what are your thoughts on this?  I am not a fan of making geolatte
> > optional/provided, but if we all deem that folding hibernate-spatial into
> > hibernate-core (ala hibernate-entitymanager) as Vlad suggests is
> desirable
> > then I will accept that
> >
> > On Mon, Jun 27, 2016, 6:50 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >
> > > Nice idea!
> > >
> > > since the modules were merged already, don't we already require
> > > geolatte-geom ?
> > > I guess some code might be intentionally designed to fail gracefully
> > > about this library being there or not, but we'd need to make sure that
> > > can be tested for it to be maintainable.
> > >
> > > My preference would be to have:
> > >  - All Dialects automatically provide the spatial extensions if the
> > > needed dependencies are in place: we could automatically alias them
> > > based on this?
> > >  - a good error message naming the missing dependencies explicitly
> > > when someone attempts to use such a Spatial extensions, but the
> > > feature was not enabled by our automatic logic.
> > >  - be able to test for these.
> > >
> > > In practice I believe this means we should still have it as an
> > > independent source module, compile and test it as an independent
> > > module, and only bundle within the ORM main jar as final distribution
> > > step.
> > >
> > > If that's too much work, I'd rather make the geolatte-geom a mandatory
> > > dependency than to have cryptic runtime failures.
> > >
> > > On 27 June 2016 at 12:41, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> > > > Hi,
> > > >
> > > > Since hibenrate-spatial has been merged into Hibernate code base,
> > > shouldn't
> > > > we merge the Dialects as well.
> > > > For instance, we have MySQL56InnoDBSpatialDialect which can simply be
> > > > merged into a MySQL56InnoDBDialect.
> > > > This way, MySQL57InnoDBDialect can take advantage of spatial queries
> as
> > > > well.
> > > >
> > > > The only drawback is that we need to add the geolatte-geom lib to
> > > > hibernate-orm.
> > > >
> > > > Let me know what you think.
> > > >
> > > > Vlad
> > > > _______________________________________________
> > > > hibernate-dev mailing list
> > > > hibernate-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>