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

On 28 June 2016 at 18:43, Steve Ebersole wrote: > I just created HHH-10901 for that. > > So we'd still have the question of merging hibernate-spatial into > hibernate-core. Personally I am against that for the dependencies. +1 I agree, my previous comment was mislead as I thought it was merged a

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

I just created HHH-10901 for that. So we'd still have the question of merging hibernate-spatial into hibernate-core. Personally I am against that for the dependencies. On Tue, Jun 28, 2016, 11:02 AM Karel Maesen wrote: > Yes, a SqlFunctionContributor would solve the problem of registering > sp

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

Yes, a SqlFunctionContributor would solve the problem of registering spatial functions. Then the only thing left are the methods defined in the SpatialDialect interface. These are helper methods for use in Criterion implementations (to generate the correct SQL syntax). I think these methods can be

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

Thanks for the clarification. However, all told I am not sure what you are suggesting. Are you suggesting that we somehow make Dialect itself expandable/mutable and hibernate-spatial hook into that to expand mutate the ORM Dialect? If it is just augmenting Types and SQLFunctions we already have

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

@Steve, besides Types a number of spatial Functions are registered for use in queries. The Dialect#contributetypes method is currently already used by Hibernate-spatial to inject to correct Types (with the correct SqlTypeDescriptors) for the SpatialDialect. On Tue, Jun 28, 2016 at 3:40 PM, Steve

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

I agree. I think keeping these separate makes the most sense. @Karel, we already have that capability wrt Types (see Dialect#contributeTypes). What else would get injected? On Tue, Jun 28, 2016 at 8:33 AM Gunnar Morling wrote: > One thing to keep in mind is that the module system of Java 9 ("

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

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 separ

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

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,

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

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 o

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

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