Is it possible to use Grails to provide Controllers and Views, Neo4j as the database and (self written) domain classes that wrap the database access and CRUD operations without the neo4j plugin?
The data I have (~10^6 Nodes, 10^7 Relationships) are very well suited to be modeled by a graph DB. The Nodes and the relationships both need to have labels and properties so they can be accessed through traversal methods that only go via certain paths in the graph. I want to use grails for the web interface because I just starting learning programming a few weeks ago and it appears to be a pretty good point to begin.
From what I understand until know is that with the Grails Neo4j-plugin, it is not possible to set relationships with properties and labels. It seems very appealing and easy to write the classes that relate to the data using the plain Neo4j-Java-API.
Additionally, if my database is already structured in a way that directly relates to Objects, what is the benefit of using ORM (or object-graph-mapping in this case)?
Unless you require Grails scaffolding and you're not depending on domain classes in Grails you can go without the GORM plugin and do the dirty work on your own.
Add the neo4j jar dependencies to your BuildConfig.groovy and expose the GraphDatabaseService and optionally the ExecutionEngine to your application context, see http://grails.org/doc/latest/guide/spring.html#springdslAdditional.
In the near future there will be 2.0 version of the Neo4j GORM plugin that uses labels and relies solely on Cypher. Relationship properties is high on the list after this release.
Related
I have to create a web service that needs to interact with a Neo4J database using the Spring framework with Spring-Data-Neo4J. This requires a static data domain model, e.g. defined labels, relations, properties.
The Problem is, that my data is based on an Ontology (via the neosemantics plugin) which could be modified in the future. It would be great if the application could automatically adopt to it. This way, the data model could be extended by editing the ontology only and no additional programming knowledge would be necessary.
Does this mean I have to generate the Spring data classes dynamically (based on the Ontology) or is there a better way to achieve this with Spring-Data-Neo4J (or should I use a different framework)?
Sure, you could come up with a way to generate a set of classes from an ontology. But that is probably going to present more problems than it solves.
An automatically-generated set of classes may not correspond to an appropriate data model for your use cases. The determination of the appropriate data model still requires a human.
Also, the new classes may be incompatible with the existing client code. And you may have to migrate the existing DB over to the new data model. Fixing all that requires humans as well.
I ended up using the Java neo4j driver instead of Spring-Data-Neo4jand a generic node class implementation only having the fields id, list of labels and a map of properties. The set labels and properties can be checked against the ontology prior to creating the nodes in the database. This way I can enforce a specific set of node labels and properties by only modifying the ontology and without having to generate the specific Spring-Data-Neo4j data classes.
good day. i have some theoretical question.
i made application that uses neo4j to traverse graphs and make some external calculations on each node. traverse process initiated by external event.
during traverse process nodes properties may change according calculation results.
this made by
new GraphDatabaseFactory().newEmbeddedDatabase(new File (this.DB_PATH));
GraphDatabaseService.traversalDescription();
now i'd like to use neo4j OGM to use domain classes in path extenders code instead self-made node-wrappers. also i`d like to use domain classes to populate DB with nodes and relations , and change properties of nodes from external source (REST for example).
But i can't find way to get Session or SessionFactory to existing and operational database.
is it possible to connect to database , created as embedded and conducting some calculations in one module , from another module by BOLT protocol, execute some queries, use OGM features?
The OGM cannot be used from path expanders / traversals (at least not easily).
To use OGM with embedded database you have 2 options
use the standard configuration as described in the reference documentation
set use Components.setDriver to set the driver manually, see e.g. this answer for details
I have a small Java web application built and I'd like to convert this to a Grails web application. My Java web application consists of Servlets, entity and hibernate for the database, and plain old java objects classes. So What's the best way of going about doing this?
I agree with Joshua for the most part. I have helped prototyped moving a java web service to Grails. I would first start with understanding the roles of the classes inside Grails (Domain classes, Controllers, Services, Filters, and CommandObject) and mapping on a whiteboard what does those roles in your current application. With hibernate as the database layer, that should be easy to port, and many service like classes can be moved over as-is. The tear up is going to come at the controller level, so make sure you think that through carefully.
You might think about refactoring your code in the Java space first if your current application does not separate responsibilities well. The cleaner your code, the more you can re-use as Grails services.
Starting with an empty Grails project I would begin by using your existing POJOs and creating Domain classes in the Grails project. From there I would then begin to model the behavior of the Servlets into Grails controllers, services, and filters. Finally I would finish with cleaning up the views and applying the styles.
That's how I would approach converting it.
I am looking to build a relatively complex Neo4J application, which I intend to split up in two separete projects, namely frontend and backend. The frontend will be HTML5 and is not relevant for this question, the backend will have a REST interface with Jersey, but it's the structure behind that REST interface that I have questions about.
Atm, this is how I envisioned it :
RESTimpl <-DATA-> Service <-DTO-> Repository <-NODE-> DAO <--> Neo4j Singleton
The general flow would be that the RESTimpl receives JSON and converts it to simple java objects like Strings, int, ... Those are then passed on to the service who creates a DTO with them. That DTO is passed on to the repository which performs all the DAO calls needed to write such a DTO to the database (one DTO may require several nodes and relations to be created). For DAO I was thinking of creating both a Core API and Cypher implementation, which has just very basic graph functions like creating a node, creating a relation, deleting a node, ... Methods which are useful for all repositories basically. The Neo4j singleton would then contain my GraphDatabaseService instance and some configuration stuff.
This is a relatively complex structure but I want the project to be very modular. Makes it easy to do Dependency Injection. (Everything will be written against an interface as well)
However, all the examples on the internet have a different implementation. They actually make their DTO's a wrapper around the Neo4J node or at least store the underlying node in the DTO. But it does allow for just a REST-Service-DAO structure.
But it doesn't allow me to change the repository implementations and put a different database behind the application.
What would be the "most correct way" to do what I want to do?
I use exactly what you've described above and I find that it works very well(one project in production, one almost there) and does not mix concerns. I don't use Spring Data but it is an option to consider.
I have defined my domain objects as standard POJO's- no Neo4j stuff in them at all. Their persistence is managed by DAO's- which contain mostly Cypher queries, and in some cases some core API work depending on complexity.
The GraphDatabase is a injected (I have two contexts- the EmbeddedGraph implementation is injected for production and the ImpermanentGraph for tests).
A REST service is exposed using Jersey which deals with domain objects and/or DTO's.
So Neo4j code is only seen in the persistence layer.
Got a couple of general convenience methods exposed to index/fetch by index etc.
I wouldn't go the wrap-Node way- tried it but found that it brings along its own set of problems and results in a somewhat smelly design. Looks like you're on the right track (to me at least)
I am doing some research on Grails and writing about what the future holds for it..
Something interesting jumped out in the RoadMap (http://grails.org/Roadmap)
GORM for REST
Anyone with more experience with Grails than me know what this would entail?
I am guessing some sort of CRUD operations through Web Services instead of using Hibernate to connect to an SQL database?
there is a JSON RESTful API for GORM which gives some insight on what GORM for REST is like:
GET on /context/api/domain-class-name returns a list of domain objects (possible arguments are the same as for the DomainClass.list() method argument map)
POST on /context/api/domain-class-name creates a new instance
GET on /context/api/domain-class-name/id retrieves the given instance
PUT on /context/api/domain-class-name/id updates the given instance by ID
DELETE on /context/api/domain-class-name/id deletes the given instance
As far as to RESTy GORM that is scheduled for Grails 2.0, here is the GORM Virtual REST domain objects discussion on Grails mailing list:
I am currently evaluating the use of grails to connect to other backend systems. Would it be possible to let the domain layer talk to CRUD REST services instead of a Database? It would be a bit like a XML backend.... We have got a very big backend where it is difficult to implement business logic, but we can manage to provide restful services. My idea is to have grails as a business / web application layer on top to deploy various systems to cross platform
This feature is scheduled for development for Grails 2.0
-- Graeme Rocher
I think the intent is to apply the scaffolding pattern to a RESTful API out of the box. There has been a JIRA entry around for several years for this.
Resulting JIRA: http://jira.grails.org/browse/GRAILS-2823
I also wouldn't be surprised if they took the dynamic finder idea and applied it to URL patterns.
GET /book/findByTitle/Dune
or
GET /book/findByTitle?title=Dune&format=json
or something like that.
I don't know exactly what is on the roadmap, but I imagine that the final product will have scaffold functionality (list,view,create,update,delete) through a RESTful interface plus some URL patterns that correspond to what you can currently do with the dynamic finders that GORM provides.
Take a look at the JAX-RS plugin. I suspect that will be the kind of thing they use.
Not that I want to rain on the parade but why would I use REST for accessing database rather than directly through hibernate. It's bound to slow down the DB access.