How do I provide a cypher query to neography ruby gem to search by relationships and date property?

Question

I am looking at the following:

https://github.com/maxdemarzi/neography/wiki/Scripts-and-queries

I have tried to come up with the value for "query" which will return the following:

• nodes that have a relationship workingOn
• created Date is yesterday (I used an integer of epoch time since it didn't seem like there was a Date type?)
• return the property value

I tried:

start n=node(id) # where id is the reference node
match n-[:workingOn]-()
where has(n.date < Date.now.to_i and n.date > Yesterday.to_i) # yesterday is a Date for yesterday
return n

Solved: I got the insight from the question I marked as having solved it, but what I did was create a query string and used interpolation to populate it with the values needed. Eg query = "Match (n) -[#{relationship}]-(n2)....etc

Answer 1

You are using antiquated Cypher syntax. If you are using a recent version of neo4j (3.1+) and have the appropriate APOC plugin installed, the following should work. (I assume that the id parameter is passed when making the query. If it isn't, replace $id with the actual ID value.)

WITH timestamp() AS now
MATCH (n)
WHERE ID(n) = $id AND
  (n)-[:workingOn]-() AND
  apoc.date.convert(apoc.date.convert(now, 'ms', 'd') - 1, 'd', 'ms') < n.date < now
RETURN n;

It uses the timestamp() function to get the current epoch time (in milliseconds), and uses the APOC function apoc.date.convert twice to get the epoch time for the start of yesterday.

It also moves the (n)-[:workingOn]-() pattern to the WHERE clause so that for each n only a single row is generated, even when that n has multiple workingOn relationships.

(The RETURN clause would actually be RETURN n.value if you wanted to return the value property of the n node.)

[UPDATE]

GrapheneDB supports plugins like APOC. See their documentation .

To search by a native neo4j ID, you need to know the ID value first. You may need to perform another query first to get it. Note, however, that it may be better for you to assign and use your own IDs instead of the native IDs, since the latter can be recycled and used for new nodes if the original is deleted.