Redisgraph: Support for the WITH clause

Created on 25 Nov 2018  路  9Comments  路  Source: RedisGraph/RedisGraph

cypher enhancement

Most helpful comment

@Raidus We do guarantee atomicity! Our threading models allows multiple simultaneous readers or one writer (any query that modifies data). If your data or request volume is large, though, I'd definitely recommend profiling a bit, because serious lock contention can definitely cause a slowdown.

As a sidenote, many of the queries you've mentioned use the WITH clause as a way of handling the issue that Cypher doesn't allow LIMIT clauses on single-part queries without an accompanying RETURN. In many cases, a dummy return allows you to work around this:

MATCH (n:User)
WHERE n.busy = false
SET n.busy = true
RETURN NULL
LIMIT 1

Would work fine in RedisGraph today, for example.

All 9 comments

Hi @K-Jo!

Will THIS work with ORDER BY and/or LIMIT? Like:

MATCH (n:User)
WHERE n.busy = false
WITH n
LIMIT 1
SET n.busy = true
MATCH (n:User)
WITH n
ORDER BY n.Followers DESC
LIMIT 10
SET n:Influence

@Raidus Correct, once we have WITH in place you'll be able to combine it with AS, ORDER BY, LIMIT and SKIP

Hi @K-Jo !

Is there any timeline for this feature? The WITH clause would simplify our application significantly. Depending on the planned release we would either wait for the release or implement a workaround using other Redis commands.

Best
Willy

@Raidus, we're actively working on WITH, and expect to release the first iteration early next week! The example queries you've provided will definitely be supported in that release.

@jeffreylovitz that are great news! we are looking forward to new release :-)

Just to verify: All redis graph queries are atomic? So there would be any conflict if many clients would query like:

MATCH (n:User) WHERE n.busy = false WITH n LIMIT 1 SET n.busy = true

@Raidus We do guarantee atomicity! Our threading models allows multiple simultaneous readers or one writer (any query that modifies data). If your data or request volume is large, though, I'd definitely recommend profiling a bit, because serious lock contention can definitely cause a slowdown.

As a sidenote, many of the queries you've mentioned use the WITH clause as a way of handling the issue that Cypher doesn't allow LIMIT clauses on single-part queries without an accompanying RETURN. In many cases, a dummy return allows you to work around this:

MATCH (n:User)
WHERE n.busy = false
SET n.busy = true
RETURN NULL
LIMIT 1

Would work fine in RedisGraph today, for example.

@jeffreylovitz thank you so much for pointing this out! Actually I tried such a query but with RETURN n and assumed that this MATCH/SET doesn't work because the returned node from this query has still the value n.busy=false. But if I query the same node then the value n.busy=true is indeed set. Thats a bit confusing for me because I expected that the returned value will be the updated one.

BTW Congratulations for the closed funding round! It's a sign that it's very valuable what you guys are doing and I love the spirit of the Redis team! :-)

@Raidus Glad that I could help! Queries that modify _and_ return data currently do return the old values, as you observed (sorry about that!). We brainstormed an efficient fix for this recently, and should be able to correct that in the near future.

We're hoping to release the first iteration of the WITH clause today. It will handle the queries we've discussed here, though not the full range of Cypher's WITH expressiveness - we'll try to document the limitations as best as possible, and improve on them quickly.

Thanks so much for your support!

380

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dandago picture dandago  路  3Comments

mdazartash picture mdazartash  路  3Comments

fantasticKe picture fantasticKe  路  5Comments

mdecuir picture mdecuir  路  12Comments

sidenAlex picture sidenAlex  路  3Comments