[OGM] Neo4J discussions
by Emmanuel Bernard
Davide and I had an interesting discussion on OxM and Neo4J with
Nicolas. We also brushed on the JCA support and lack of Neo4J interest
in it.
This is a dump of the conversation and a way to continue the
conversation in the open.
## JCA support
Provided outside of Neo4J's team help.
Original author has unplugged from the internet.
## Blueprints
Nicolas, recommended us to look at Blueprints which offers an
abstraction over Neo4J APIs with clearer concepts. Blueprints is
implemented for other Graph databases so we would gain support for them
too for "free".
https://github.com/tinkerpop/blueprints/wiki
Davide looked at it and our use of Neo4J seems simple enough that we
could switch to Blueprints easily.
## Mapping model
We discuss the various mapping modeling strategies to represent an
object graph in a GraphDB.
### Hibernate OGM's approach (aka classic)
An entity is mapped as a node. A property is added to save the name of the
table that maps the entity.
Attributes of the entity are mapped as properties.
A unidirectional association is mapped as a neo4j Relationship where the
starting node is the owner of the relationship. The type of the
relationship is the name of the association.
A bidirectional association is mapped using two relationships, one for each
direction.
A sequence is stored in a node with the value stored in a property, Every
time we need to update the value of the sequence we acquire a lock on the
node.
Node and relationships are stored into two separate lucene indexes and when
I need to retrieve them I use a lucene query.
I've developed the code using Neo4j 1.9.4 (I'm now moving to Neo4j 2)
### Gaedo (aka vertex per property)
Each element (be it a model
entity or one of its property) was mapped directly as a node in graph.
Look here for more infos :
http://riduidel.github.io/gaedo/site/0.4.21/gaedo-blueprints/1_gaedo_grap...
The main advantage of this approach is that we do not have to browse
(and maintain) an index to find objects for which the property "name"
has the value "foo". instead, we directly locate the vertex holding
that value, then back-navigate the links named "name" to find objects
..; well, I guess you can see the advantage of this approach.
Which takes me back to that divide between properties stored as
properties of vertex, or as distant vertices.
Each approach has its advantage :
- one vertex per literal ensures easy search through graph navigation
languages (be them gremlin, cypher, or any other one you find) and
some nice-to-architect similarity for all vertices (in my case, each
graph vertex has two properties mimicking the ones found in RDF
concepts : kind and value). The cost of it being easier lock (it
indeed seems neo4j requires a lock on each vertex when adding/removing
an edge connecting them)
- one property per literal avoids those locking issues, but obviously
make search really dependant upon indices, and furthermore impossible
to write using "pure" graph query language,a s queries will sometimes
rely upon indices navigation, and sometimes upon graph navigation,
which maybe hard to differentiate - or maybe not.
### Mapping conclusion
After a few back and forth we concluded that the vertex per property
approach does not offer much advantages including in query performances.
Quite the contrary, there are a few advantages to the classic and
natural approach like lower deadlock rate, possibly faster queries etc).
So we will start with this approach in Hibernate OGM and see where it
leads us.
### Data points
Some info on the Neo4J storage
http://digitalstain.blogspot.fr/2011/11/rooting-out-redundancy-new-neo4j....
## Id generators
I would be nice to implement a generator that uses Neo4J's internal id
property generated for each node. While it is not monotonic, it is a
viable id generator option.
Note that seuqnce mapping still requires to store the sequence seed and
using the Neo4J id property won't be of help here.
That's a condensed version of the discussion. We can continue from there
if needed.
Emmanuel
12 years, 2 months
Asciidoctor and Gradle
by Steve Ebersole
I just pushed the initial work getting Asciidoctor building through Gradle.
I have done zero styling or layout etc. This is just the initial
ability to generate Asciidoctor docs via Gradle.
At the moment there is just one doc (the ServiceRegistry guide that is
still WiP) that is rendered to just HTML. If you want to give it a try,
cd into the documentation directory and execute `gradle
generateRegistryGuideHtml`. The output for now goes into
target/asciidoc/topical/html
12 years, 2 months
[HV] HV and RESTEasy integration
by Emmanuel Bernard
I was once again working on the demo showing Bean Validation and its
integration inside Java EE 7.
When you put constraints on the method parameter of a JAX-RS call, you
get a nice rendering of the error on the client side (basically the
HTTP entity returns a JSON representation of the errors).
But if from this method you call JPA or Bean Validation directly and a
ConstraintViolationException is raised, then this exception is processed
as a generic exception crossing RESTEasy.
Would it make sense you think to treat ConstraintViolationException
raised by JAX-RS methods like we would do parameter or return value
exceptions?
The error handling would be the same / unified. I might miss some parts
of the whole picture so this email is really for discussions.
WDYT?
Emmanuel
12 years, 2 months
Search compatibility with WildFly
by Sanne Grinovero
I'm working to replace the integration tests using the now outdated
EAP Alphas with WildFly 8.0.0.Beta1, which also has the benefit to
remove the need for the enterprise repository.
This requires:
- updating to ORM 4.3
- updating to Infinispan 6.0.x
- building the project with Java7
Java7 is needed as the Arquillian connectors for WildFly are compiled
without Java6 compatibility, my guess is the whole WildFly needs it
too.
As a consequence, that would mean that Hibernate Search from 4.5.x
would need to be compiled with Java7, ideally attempting to maintain
Java6 compatibility as possible (Animal sniffer & co).
Thoughts?
Cheers,
Sanne
12 years, 2 months
[OGM] Requiring Java 7?
by Gunnar Morling
Hi,
In the context of the notorious JavaDoc CSS issue ([OGM-341] - an updated
stylesheet is required when building our projects with Java 7) Sanne,
Davide and I were wondering whether we should take the opportunity and
actually require Java 7 as the minimum version for Hibernate OGM, not only
at build but also at run time.
This would give us some interesting opportunities for the implementation,
language-wise (e.g. diamond operator, multi-catch) as well as library-wise
(e.g. the fork/join framework). On the downside we might exclude some users
who are still running on Java 6.
Given that OGM is a rather new project, I'd assume though that at this
point most users are in a more experimental stage of using it. I'd thus
also expect that they use a more current version than 6 which has reached
the end of its (public) support lifecycle. So this change might not effect
many in reality.
Any thoughts?
--Gunnar
[OGM-341] https://hibernate.atlassian.net/browse/OGM-341
12 years, 2 months
Re: [hibernate-dev] [OGM] Requiring Java 7?
by Gunnar Morling
2013/10/9 Steve Ebersole <steven.ebersole(a)gmail.com>
> What is gained needs to be balanced by what you are giving up.
>
> OGM itself is new, but at the end of the day its a JPA provider which is
> not new. Basing on Java 7 will limit adaption from folks wanting to drop
> OGM in to their app as replacement for their JPA provider to give it a spin
> in certain environments.
Yes, that's true. Hard to say how many such cases there would be without
some real figures. Maybe it's just not worth taking the risk.
> On Wed 09 Oct 2013 07:54:14 AM CDT, Sanne Grinovero wrote:
>
>> +1 for requiring Java7
>>
>> On 9 October 2013 12:55, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>>
>>> Hi,
>>>
>>> In the context of the notorious JavaDoc CSS issue ([OGM-341] - an updated
>>> stylesheet is required when building our projects with Java 7) Sanne,
>>> Davide and I were wondering whether we should take the opportunity and
>>> actually require Java 7 as the minimum version for Hibernate OGM, not
>>> only
>>> at build but also at run time.
>>>
>>> This would give us some interesting opportunities for the implementation,
>>> language-wise (e.g. diamond operator, multi-catch) as well as
>>> library-wise
>>> (e.g. the fork/join framework). On the downside we might exclude some
>>> users
>>> who are still running on Java 6.
>>>
>>> Given that OGM is a rather new project, I'd assume though that at this
>>> point most users are in a more experimental stage of using it. I'd thus
>>> also expect that they use a more current version than 6 which has reached
>>> the end of its (public) support lifecycle. So this change might not
>>> effect
>>> many in reality.
>>>
>>> Any thoughts?
>>>
>>> --Gunnar
>>>
>>> [OGM-341] https://hibernate.atlassian.**net/browse/OGM-341<https://hibernate.atlassian.net/browse/OGM-341>
>>> ______________________________**_________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>
>> ______________________________**_________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>
>
12 years, 2 months
starting release
by Steve Ebersole
Per subject. Please dont push anything to upstream master until the
release is done. Thanks.
12 years, 2 months
