[hibernate-dev] 6.0 - Type redesign

I've been reading the wiki and email archives, and I have some notes for what needs to be decided before it needs to become retrofitted. After all, all that retrofitting is what the reason the types need to be redesigned. LiteralType.objectToSQLString is only used to append the

Re: [hibernate-dev] [OGM] Neo4j integration dependencies

Splitting in 3 modules sounds good to me. I was sure in past there was some opposition about having additional modules. I might have imagined it On Wed, Oct 19, 2016 at 10:59 AM, Sanne Grinovero wrote: > On 19 October 2016 at 10:44, Yoann Rodiere

Re: [hibernate-dev] [OGM] Neo4j integration dependencies

On 19 October 2016 at 10:44, Yoann Rodiere wrote: > Is there any particular reason why we would not want to create three > artifacts, besides backward compatibility? It seems the obvious and ideal > solution, but I might be missing something. > > If there is common code, we

Re: [hibernate-dev] [OGM] Neo4j integration dependencies

I would prefer to see these modules split as 3 different Maven modules, but I wouldn't personally consider such work a priority. Splitting them up would make for "lighter" fragments for e.g. Swarm, but at the cost of a couple more paragraphs of documentation which needs to be understood (more

Re: [hibernate-dev] [OGM] Neo4j integration dependencies

Is there any particular reason why we would not want to create three artifacts, besides backward compatibility? It seems the obvious and ideal solution, but I might be missing something. If there is common code, we can always create a fourth -neo4j-core artifact that would have no interest to

[hibernate-dev] [OGM] Neo4j integration dependencies

The integration with Neo4j in OGM makes it possible for a user to select the strategy that he wants to use to connect to an embedded or remote Neo4j instance. There are 3 possible options: 1) Embedded mode, Neo4j run in the same JVM 2) Remote via HTTP interface using RestEasy 3) Remote via the