Hiya Andres,
I love subqueries in SQL. And in the particular scenario that I'm dealing
with, it's certainly going to work, because I can wrap the predicate inside
an EXISTS whereas with UNION or OPTIONAL I'd have to rearrange branches in
the AST (mine, not Cyphers). It's still a bit more verbose
Wes,
I'd say YES to both examples: both have correct syntax, though probably
incorrect semantics.
In the first case where one's searching for unconnected nodes, it would
return a Cartesian of the set over itself, because '*' means return all
identifiers. In the second case, it's a Cartesian of t
+1 for subqueries.
On Wed, Oct 29, 2014 at 6:00 AM, Andres Taylor <
andres.tay...@neotechnology.com> wrote:
> Hiya!
>
> I think there is a lot of circumstances where being able to express things
> like this makes sense. Michael and Wes have useful workarounds, but longer
> term, I'm growing more
Hiya!
I think there is a lot of circumstances where being able to express things
like this makes sense. Michael and Wes have useful workarounds, but longer
term, I'm growing more and more convinced that we need better sub query
support. Something similar to SQL's EXISTS method would solve it witho
For generating cypher, it seems like stringing OR together is easier and
more flexible than UNION.
Back to your original proposal. While I can see how it might help some of
your queries be simpler, I think there are other cases that might not be as
desirable if we were to allow identifier binding
For an optional match the path expression returns a empty collection if
there is no match. So you could test for that.
You can return values by either returning the path, or by using
head(extract(p in (c)-->() | last(p))) to return "s"
I still think that with your UI, the UNIONs would represent
Yes, Wes, that solves the simple case where only 2 nodes are involved.
What about the situation where 4 or 5 nodes on the path? with a coupe of
OR's?
It's a bit late for me right now. But I will try come up with a more
concrete example tomorrow.
Cheers,
Kai
On Tue, Oct 28, 2014 at 10:28 PM, We
How about this? Defer predicates until you match more than you need, then
double check what you need to confirm in WHERE.
MATCH (c:circle)
OPTIONAL MATCH (c)-->(s:square)
WITH c, s
WHERE c.id = 4
OR ((c)-->(s) AND s.id < 4)
RETURN c,s
Wes
On Wed, Oct 29, 2014 at 1:13 AM, S. Kai Chen
wrote:
Hi, Michael,
Thanks for the quick response! And sorry about my own late reply: I had to
go to a meeting right after I sent the first post and have just gotten back
right now.
Interesting suggestion with using path expression and collection
predicates. How would you include an optional path here
You can also do number 3) because you actually don't need "s"
match (c:circle) where (c.id=4) or ( (c)-->(:square{id:1}) ) return c
Only #4 is trickier but still possible, only not so nice to read :)
*I think union is still the better choice here as you combine 2 different
use-cases:*
match (c:
Hi,
I'm not sure if this is the right place to submit this. I was going to
open an FR ticket on github but changed my mind because I thought maybe
it's better to have a discussion here first.
I've run into a couple of places where being able to say something like
match (n ) /* criteria
11 matches
Mail list logo
