My personal opinion is: OGMs should support CQRS (command query responsibility
separation)
#1 OGM should only cover minimal CRUD operations which map 1:1 to the the
appropriate cypher statements to create,read, update only tiny subgraphs
No fancy fetch strategies or cascading updates or whatever, or lazy
loading ftm
#2 The power of graph querying should be left to Cypher where you can define
arbitrarily complex queries for read and other operations, the results of those
complex read operations should be easily mappable in any kind of DTO like
view-object tree or graph/network without any further need for annotations etc.
(i.e. what we currently do with @QueryResult but much more powerful)
For SDN I want to have (ideal world/some future).
#1 slick and fast java based cypher driver that works both with embedded and
server (like the jdbc driver) and also exposes transactions over the wire
#2 a minimal java-only OGM as described above
#3 integration in SDN which provides the entity metadata to the OGM and adds
fancy things like the repositories and spring integration on top of it
Now the only thing missing is unlimited time, bandwidth and focus :)
Michael
Am 18.03.2014 um 22:06 schrieb Lorenzo Speranzoni (@inserpio)
<[email protected]>:
> Hi Phillipe, thanks for your precious reply.
>
> I'm actually thinking that in general we should decide whether to discard or
> use Object Graph Mapping modelling more or less the same way we decide to use
> Hibernate (or a similar Object Relational Mapping) in the relational world:
> automatic mapping between my object domain model and the database sounds
> useful, don't you agree? (tons of Node.getProperty + MyDomainObj.setProperty
> saved). Hibernate also solves object-relational impedance mismatch, but with
> a graph database this comes for free.
>
> Furthermore, for companies - as my own one - that use to develop applications
> using the Spring Framework, Spring Data Neo4j (not necessarily the OGM part)
> seems a natural solution when introducing a graph database.
>
> Any feedback appreciated! :)
>
> Thank you again!
> Lorenzo
>
> Il giorno lunedì 17 marzo 2014 21:04:32 UTC+1, Philippe Baumard ha scritto:
> @Lorenzo Speranzoni
>
> Hi,
> I am developping an application with Noe4j (www.bontirage.com).
> I was surprised by the number of possibilities to use Neo4j.
> - Embedded,
> - REST API,
> - Cypher,
> - Sprind Data,
>
> What to do?
> i did research about the performance i my choice was Embedded Database with
> API.
>
> I disapprouve completely Sping Data Neo4j.
> Because of the performance, and the versions updates too slow.
>
> Cypher is a marvelous language but i don't think it is the tools for a large
> number of connections.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Neo4j" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
