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] 6.0 - Type redesign

Abstraction from JDBC is not my primary concern atm tbh. I think ValueExtractor/ValueBinder *could* be made to work in a way that is datastore agnostic (not JDBC dependent). Like I said, I am not a fan of `int[] Type#sqlTypes`. I think that ought to be `SqlTypeDescriptor[] Type#getSqlTypeDescrip

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] 6.0 - Type redesign

Hi Steve, Yes, assuming ValueExtractor/ValueBinder are going to be sufficiently generified (i.e. no usage of java.sql.* types such as ResultSet, PreparedStatement etc. in the method signatures), it might fly for OGM, too. No idea though how feasible that'd be. Once you have some sort of PoC, we s

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] 6.0 - Type redesign

Ok, I need to move forward on this and I have gotten enough affirmative feedback to ahead. On Fri, Jun 24, 2016 at 6:24 PM Steve Ebersole wrote: > This is all part of the to-be-decided read/write part of the new Type > contract. I propose, as discussed in the wiki, that we have Type return > Va

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] Redis and TTL

I might be dumb but I can't figure out a use case where you would want an external app to set a TTL and OGM to manipulate the same objects while keeping the TTL originally set. It really looks weird to me. Anyway, if it's really a use case, I think Gunnar's proposal does fit and will allow to remo

Re: [hibernate-dev] Redis and TTL

Hi Gunnar, see my responses in-line. Best regards, Mark > Am 28.06.2016 um 12:55 schrieb Gunnar Morling : > > Hi, > > > [...] The TTL is not configured in OGM for this use-case because the TTL > > might be determined somehow dynamic by the first client. > > Yes, but this kind of issue is th

Re: [hibernate-dev] Redis and TTL

Hi, > [...] The TTL is not configured in OGM for this use-case because the TTL might be determined somehow dynamic by the first client. Yes, but this kind of issue is the crux when integrating different applications through the database. If you can't avoid it, you at least should use the same con