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

[Karel Maesen]

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
>