Over a million developers have joined DZone.

Neo4j: Shortest Path With and Without Cypher

· Database Zone

To stay on top of the changing nature of the data connectivity world and to help enterprises navigate these changes, download this whitepaper from Progress Data Direct that explores the results of the 2016 Data Connectivity Outlook survey.

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.

 

Turn Data Into a Powerful Asset, Not an Obstacle with Democratize Your Data, a Progress Data Direct whitepaper that explains how to provide data access for your users anywhere, anytime and from any source.

Topics:

Published at DZone with permission of Mark Needham, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

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

{{ parent.tldr }}

{{ parent.urlSource.name }}