GraphAware Blog

With MERGE set to replace CREATE UNIQUEat some time, the behavior of MERGE can sometimes be tricky to understand.

Efficient counting of relationships in Neo4j was the cornerstone of my Master Thesisand the reason the very first GraphAware Frameworkmodule called the Relationship Count Module was born. The improvements in Neo4j 2.1around dense nodes and the addition of getDegree(…) methods on the Node interface made me eager to do some benchmarking around relationship counts again.

When one obtains a graph data from a measurement on a real world network, it is sometimes useful to make comparison witha random graph. Such graph is characterised by certain degree distribution, which you can imagine to be a list of degreesof nodes present in the network. The most interesting distributions have certain functional dependence which allowsone to infer what processes are dominant in formation of the network. The processes consequently characterise therelationships between the nodes.

One of the main goals of the GraphAware Framework is to simplify andspeed up development with Neo4j. Although it is called a “framework” for reasons explained elsewhere, today we willsimply treat it as a library of useful, tested, and documented Java code. The feature we will introduce is calledImproved Transaction Event API, which is exactly what it says on the tin.

A couple of days ago, I wrote about unit testing with GraphUnit.GraphUnit tested the state of an embedded Neo4j database. What if you run Neo4j in standalone server mode?Fortunately, you can still test it and match subgraphs using the GraphAware Neo4j RestTest library.

Testing the state of an Embedded Neo4j database is now much easier if you use GraphUnit, a component of the GraphAware Neo4j Framework.

Recently, we announced the GraphAware Framework. Today, I would like to introduce its first feature called GraphUnit. GraphUnit is a component that helps Java developers unit test their code that talks to Neo4j and mutates data.

In this short blog post, I would like to introduce the GraphAware Neo4j Framework.Its goal is very ambitious: we’d like to make it as useful for Neo4j developers, as the Spring Framework is for Java developers. The Framework aims at speeding up development with Neo4j by providing a platform for building useful generic aswell as domain-specific functionality, analytical capabilities, graph algorithms, and more.

In the last post of our “Neo4j Modelling for Beginners” series,we looked at bidirectional relationships. In this post, we compare the implications of qualifying relationships byusing different relationship types versus using relationship properties.

Transitioning from the relational world to the beautiful world of graphs requires a shift in thinking about data. Althoughgraphs are often much more intuitive than tables, there are certain mistakes peopletend to make when modelling their data as a graph for the first time. In this article, we look at one common sourceof confusion: bidirectional relationships.