Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Thoughts on Software Development Neo4j: Shortest Path With and Without Cypher

DZone's Guide to

Thoughts on Software Development Neo4j: Shortest Path With and Without Cypher

· Java Zone ·
Free Resource

Build vs Buy a Data Quality Solution: Which is Best for You? Gain insights on a hybrid approach. Download white paper now!

I was looking back at some code I wrote a few months ago to query a neo4j database to find the shortest path between two people via the colleagues relationships that exist.

The initial code, written using neography, looked like this:

neo = Neography::Rest.new
 
start_node = neo.get_node(start_node_id)
destination_node = neo.get_node(destination_node_id)
 
neo.get_paths(start_node,
              destination_node,
              { "type" => "colleagues" },
              depth = 3,
              algorithm = "shortestPath")

The neography code eventually makes a POST request to /node/{start_id}/paths and provides a JSON payload containing the other information about the query.

It works fine and is pretty readable but since I wrote it I’ve learnt how to write queries using the cypher query language so I thought it would be interesting to contrast the two bits of code against each other.

This is the equivalent written using cypher:

query =  "START source=node(#{start_node_id}), destination=node(#{destination_node_id})"
query << "MATCH p = allShortestPaths(source-[r:colleagues*..3]->destination)"
query << "RETURN NODES(p)"
 
neo.execute_query(query)

The amount of lines of code is pretty similar but the thing I like about cypher is that it feels much more declarative and therefore, I think at least, easier to understand.

Having said that, the learning curve for the non-cypher API is a bit easier and it’s probably best to start with that to get a feel of what sorts of things you can do with a graph.

When I first started learning cypher I was always forgetting which order to put the different key words and what the syntax was for selecting your starting node.

After a while you do get the hang of it though and it starts to feel like any other programming language.

If we didn’t have the node ids of our source and destination nodes but we had two people’s names which had been stored in a ‘people’ Lucene index then we could just as easily find the path between them like this:

START source=node:people(name="Mark Needham"), destination=node:people(name="Cameron Swords")
MATCH p = allShortestPaths(source-[r:colleagues*..3]->destination)
RETURN NODES(p)

I use cypher for pretty much everything I do when reading from the graph and since version 1.8 M01 it’s been possible to construct queries which mutate the graph as well.

Build vs Buy a Data Quality Solution: Which is Best for You? Maintaining high quality data is essential for operational efficiency, meaningful analytics and good long-term customer relationships. But, when dealing with multiple sources of data, data quality becomes complex, so you need to know when you should build a custom data quality tools effort over canned solutions. Download our whitepaper for more insights into a hybrid approach.

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}