We currently use gremlin.net library in a net core 3.0 application to connect to Azure Cosmos db. We would like to connect to neo4j.
Can we use same gremlin.net library for neo4j? Assuming gremlin
server is installed.
Will Neo4j.Driver library support gremlin
queries? What exact library to use?
Any code sample to connect and
create a node in neo4j using gremlin library for a .net core 3.0
application?
Is neo4j really a better graph model than Azure cosmos?
Can we use same gremlin.net library for neo4j? Assuming gremlin server is installed.
Yes, assuming you mean Gremlin.Net and yes, Gremlin Server should be installed hosting neo4j.
Will Neo4j.Driver library support gremlin queries? What exact library to use?
I don't think that's possible. Neo4j drivers will support Cypher based queries, not Gremlin.
Any code sample to connect and create a node in neo4j using gremlin library for a .net core 3.0 application?
The beauty of Gremlin is that the code examples for one graph database are the same for any other and for the most part, Gremlin in Java is the same as Gremlin in .NET or any other programming language (aside from changes that make Gremlin more ergonomic to the programming language itself). So, if you want to create a node then it's always going to be:
using static Gremlin.Net.Process.Traversal.AnonymousTraversalSource;
var g = Traversal().WithRemote(
new DriverRemoteConnection(new GremlinClient(new GremlinServer("localhost", 8182))));
g.AddV("person").Property("name","Bob").Iterate();
Is neo4j really a better graph model than Azure cosmos?
My personal opinion is that you try them both and determine which is better for yourself given you requirements. That is the choice that Apache TinkerPop and Gremlin help to give you in that you can try lots and lots of different graph systems out there to find the one best suited to your needs.
as I was wandering in the Web looking for a Gremlin implementation for Neo4j I found these two possible solutions:
https://github.com/thinkaurelius/neo4j-gremlin-plugin
http://tinkerpop.incubator.apache.org/docs/3.0.2-incubating/#neo4j-gremlin
Does anybody know what is the difference between the two in practice?
I saw that 1. is a Neo4j plugin while it's not really clear to me what the second is, and if it would lock the entire database thus not allowing other connections (I noticed that it requires the path to the data folder).
Which one is preferred in the neo4j community?
Cheers,
Alberto
I'm not sure there's really a difference as there isn't a direct comparison to be made. The second link is to the TinkerPop project and specifically to the Neo4j implementation of TinkerPop APIs. It runs in an embedded mode and does not yet have support for HA (though we hope to have that soon). The Neo4j implementation can be run in Gremlin Server which let's you send Gremlin to it as a REST, websockets, etc endpoint.
The project in the first link you provided uses that implementation to allow you to send Gremlin to Neo4j Server - so the first project depends on the second.
Your rule of thumb should be activity in the source code.
neo4j-gremlin-plugin has 3 commits this year - https://github.com/thinkaurelius/neo4j-gremlin-plugin/commits/master
tikerpop is much more active - https://github.com/apache/incubator-tinkerpop/commits/master/neo4j-gremlin/src/main/java/org/apache/tinkerpop/gremlin/neo4j
neo4j-gremlin-plugin
Extending existing Neo4j server with support for Gremlin Query Language.
TinkerPop Neo4j-Gremlin
Extending Gremlin console with support for Neo4j server.
I am considering Neo4J for some project. I recall reading somewhere that multi-document ACID transactions are only supported for embedded database, but not for the standalone one. Searching at the Neo4J site, I could not find any info about this. Some more information about this, or some pointers could help. Thank you.
Neo4j itself supports now transactions over the wire with 2.0
See: http://docs.neo4j.org/chunked/milestone/rest-api-transactional.html
Spring Data Neo4j does not yet and it will take a while until we get there, as it means to rewrite the core to use cypher throughout which it doesn't do now.
In order to store hierarchical data, can a graph database (Neo4j) be viewed as an alternative to JCR based solutions (ModeShape, JackRabbit)? Or do they belong to 2 different level of abstraction meaning that a JCR implementation could use Neo4j under the hood?
Thank you for your help.
Both, people are building CMS applications with Neo4j as storage backend (see http://structr.org)
A JCR implementation could also be done using Neo4j, some people worked on that in the past, we also have a group using Neo4j as backend storage for Apache Shindig.
You also might want to take a look at OrientDB (http://www.orientdb.org/) which combines features of a Graph-DB (as Neo4j) with those of a Document-DB. There even seems to be a prototype implementation using OrientDB as a storage-adapter for Jackrabbit (https://github.com/eiswind/jackrabbit-orient) that illustrates the implementation of such a hybrid approach.
EJB achieved many improvements in 3.x versions, Spring is also commonly used and version 3 is a good alternative.
There are many articles on web, but no exact comparison about ejb3x versus spring3x.. Do you have any ideas about them, in real world examples which one is better at which conditions?
For example, we want to separate db and server, which means our application will be on a server, our database will be in another server.. EJB remoting vs Cluster4Spring etc ?
Doing everyting #Annotation is always good? configuration never needed?
For your use case where the application runs on one server and the database runs on another, the choice between EJB and Spring is irrelevant. Every platforms supports this, be it a Java SE application, a simple Servlet container like Tomcat or Jetty, PHP, Ruby on Rails, or whatever.
You don't need any kind of explicit remoting for that. You just define a datasource, provide the URL where your DB server lives and that's it.
That said, both EJB and Spring Beans do make it easier to work with datasources. They both help you defining a datasource, injecting it in beans and managing transactions associated with them.
Of the two, EJB (and Java EE in general) is more lightweight and adheres more to the convention over configuration principle. Spring requires more verbosity to get the same things and depends a lot on XML files which can quickly become very big and unwieldy. The flip side of the coin is that Spring can be less magical and you might feel more in control after having everything you want spelled out.
Another issue is the way EJB and Spring are developed.
EJB is free (as in free beer), open-source and non-proprietary. There are implementations of EJB being made by non profit organizations (Apache), open source companies (Redhat/JBoss) and deeply commercial closed source enterprises (IBM). I personally would avoid the latter, but to each his own.
Spring on the other hand is free and open-source, but strongly proprietary. There is only one company making Spring and that's Springsource. If you don't agree with Rod, then tough luck for you. This is not necessarily a bad thing, but a difference you might want to be aware of.
Doing everyting #Annotation is always good? configuration never needed?
It's an endless debate really. Some argue that XML is hard to maintain, others argue that annotations pollute an otherwise pure POJO model.
I think that annotating a bean as being an EJB stateless bean (#Stateless) or a JPA entity (#Entity) is more cleanly done using annotations. Same goes for the #EJB or #Inject dependency injections. On the other hand, I prefer JPQL named queries to be in XML files instead of annotations, and injections that represent pure configuration data (like a max value for something) to be in XML as well.
In Java EE, every annotation can also be specified in XML. If both the annotation and the XML equivalent are present, the XML overrules the annotation. This makes it really convenient to start with an annotation for the default case, but override it later via XML for a specific use case.
The current preference in Java EE seems to be more towards (simple) annotations combined with a large amount of convention over configuration.
The real question you should be asking is CDI/EJB or Spring
It's often not Spring vs EJB, but Spring vs Java EE. EJB itself compares to Spring Beans. Both of them are a kind of managed beans running inside a container (the EJB container resp. Spring container).
Overall the two technologies are rather similar. Reza Rahman did a great comparison between the two a while back.
EJB's are more advantageous because of standardization. If you are working with a lightweight application I think going with Spring is fine but if you expect that your application will be big and will require lots of memory access and data connections access you may consider starting your development with EJBs. The main reason being clustering and load balancing are built into the EJB framework.
In an EJB environment, when an EAR ('E'nterprise 'AR'chive) is deployed, it may be deployed with multiple EJBs beans that each could have a specific purpose. Let say you wrote a bean for user management and another bean for product management. Maybe one day you find that your user services way exceed your products access services, and you want to move your user bean to a different server on a different machine. This can actually be done in runtime without altering your code. Beans can be moved between servers and databases, to accomodate clustering and load/data balancing without affecting your developers or your users because most of it can be configured at the deployment level.
Another reason for supporting a standard is knowing that most large third party vendors will likely support it resulting in less issues when integrating with new standard/service/technology - and let's face it, those come out like new flavours of ice-cream. And if it is in a public specification new start-up companies or kind developers can create an open-source version.
http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html
It is most unfortunate that even the most intelligent designers or programmers cannot predict which of their features may or may not be embraced by the development community which is the main reason software becomes bloated... Java EE is definitely that!
Choose one or the other, but not both.
My personal preference is Spring. I've used on projects with great success for the past six years. It's as solid as any software out there.
Spring can work with EJBs if you choose to have them in your app, but I don't believe the reverse is true.
I would recommend separate physical machines for web, app, and database servers if you can afford it.
Spring can work with several remoting options, including SOAP and REST web services. A comparison of Spring beans with EJB is beyond the scope of this question. I don't see what it has to do with your implementation. If you use Spring POJO services they're in-memory rather than requiring another network hop like remote EJBs. Think of Fowler's Law of Distributed Objects: "Don't". Only introduce latency with good reason.
I'd mention unit testing here.
In common web application (controller->service->data->...->view) EJB and Spring both provide similar result, but spring offers easier testing.
In my humble experience the way you develop is different in couple of aspects:
Unit test (spring wins). In spring its done pretty stright forward, while in ejb you have to use Arqullian with ShrinkWrap (sic!) which is slow to run on every build.
Persistence (ejb wins). In spring there is struggle around it, i.e. google "how to autowire persistence in entity listener" http://bit.ly/1P6u5WO
Configuration (ejb wins). As newbie coming to spring from ejb I was surprised by swarm of annotations and .xml files.
EJB 3.1 is the best while being the standard for Java 6 EE applications.
Spring still does not support Java 6 CDI(weld) also still depends a lot on XML configuration. EJB 3.1 is powerful and smart.
I think that Spring 3.1 doesn't need any XML configuration. You have the option to use annotations for configuration.