Thanks Michael!
I looked for a function like that, but I sure missed it!
Thanks again!
On August 20, 2016 4:33:11 AM MDT, Michael Hunger
<michael.hun...@neotechnology.com> wrote:
>Hey,
>
>
>sorry for the delay. You could use the allShortestPaths option too.
>
>And shortest paths actually take predicates into account that follow it
>in
>the where clause.
>
>I don't know how you got this query to run, because UNWIND is not a
>function but a clause:
>
>match path = shortestPath( (n)-[*]->(m) )
>return collect(distinct unwind(nodes(path))), collect(distinct
>unwind(rels(path)))
>
>
>For your other query, the initial lookup of those nodes will be slow
>(it has to scan the full graph) b/c you don't have a label (using an
>index) on them.
>
>You probably also want to add a direction (if it makes sense)
>
>
>Sorry I wrote the original statement just out of the top of my head,
>here
>is the fixed version
>
>// bind n, m, limit rel-type(s)
>match path = shortestPath( (n)-[*]->(m) )
>// optionally WHERE with predicates for the shortest paths
>unwind nodes(path) as node
>with collect(distinct node) as nodes, collect(path) as paths
>unwind paths as path
>unwind rels(path) as r
>with collect(distinct r) as relationships, nodes
>return count(*)
>
>// enable use of indexes, even if "Node" is just a generic label (I
>still
>think that using label-sets instad of nodetype is better
> MATCH (start:Node) WHERE start.nodetype = 'Drone' AND
>start.designation = {name}
> MATCH (m:Node) WHERE m.nodetype IN {nodetypes}
> MATCH p = shortestPath( (start)-[:`*%s`**]-(m) )
>// this spans up a cross product between ALL nodes and ALL rels of the
>paths which can potentially become huge
>// you can check it with returning count(*), count(distinct n),
>count(distinct r) after the two unwinds
> UNWIND nodes(p) AS n
> UNWIND rels(p) AS r
> RETURN [x in COLLECT(DISTINCT n) WHERE x.nodetype in {nodetypes}]
>AS nodes,
> COLLECT(DISTINCT r) AS relationships
>
>On Mon, Aug 8, 2016 at 12:40 PM, Alan Robertson <al...@unix.sh> wrote:
>
>> I had written up my problem here too:
>> http://assimilationsystems.com/2016/07/03/assimilation-
>> subgraph-queries/
>>
>> Here's a thought which occurred to me while sleeping last night...
>> The two ways I've done it are:
>>
>> 1. shortest paths from initial node set
>> 2. all paths
>>
>> As noted in the original email thread below, the problems I ran into
>are:
>>
>> 1. Shortest paths produces all nodes, but misses some
>relationships I
>> care about.
>> 2. All paths produces all nodes and relationships but takes a
>really
>> long time and often times out.
>>
>> A way which occurred to me while sleeping tonight was to create a
>2-step
>> query like this:
>>
>> Compute the set of shortest paths to get the set of nodes (as in (1)
>> above). Ignore the relationships produced.
>> From that set of nodes (n) compute (n)-[:a|b|c|d]-(n) and return 'n',
>> relationships.
>>
>> If Cypher won't let me compute from 'n' to 'n', then compute the from
>> n-[:a|b|c|d]-m WHERE m.nodetype is in the same set of node types as
>was in
>> the original constraint. Then return n, relationships. [Although it's
>> obvious, I'll mention that the difference is that the second query
>only
>> follows a single level of relationship].
>>
>> It still might need a little experimentation...
>>
>> Any thoughts?
>>
>> I'm going back to bed now. Will look into it some more in the
>morning...
>> ;-)
>>
>>
>>
>> On 07/21/2016 02:09 PM, Alan Robertson wrote:
>>
>> On 04/28/2016 03:32 PM, Alan Robertson wrote:
>>
>> The query isn't quite right. It has an error in it (variable n
>already
>> used) and something about the order of operations causes it to return
>more
>> than one row - with duplicates ;-)
>>
>> But this one seems to do the trick:
>>
>> match path = shortestPath( (n)-[*]->(m) )
>> return collect(distinct unwind(nodes(path))), collect(distinct
>unwind(rels(path)))
>>
>> That query is quite fast -- but...
>>
>> I don't actually want *only* the shortest paths, I want all the paths
>> that involve those relationships.
>>
>> But if I delete the shortestPath() function call it runs so long I
>get an
>> HTTP timeout on many of these queries. I restrict the types of
>> relationships with [:rel1type|:rel2type|:etctype*]. And even though
>the
>> result only includes one or two additional paths, it runs like 100
>times
>> slower - and often just times out via REST (via Py2neo).
>>
>> That's really disappointing.
>>
>> Does anyone have a suggestion on how to make this faster - or at
>least not
>> time out?
>>
>>
>>
>> --
>>
>> Alan Robertson / CTO
>> al...@assimilationsystems.com / +1 303.947.7999
>>
>> Assimilation Systems Limited
>> http://AssimilationSystems.com
>>
>> [image: Twitter] <https://twitter.com/ossalanr> [image: Linkedin]
>> <https://www.linkedin.com/in/alanr> [image: skype]
>> <https://htmlsig.com/skype?username=alanr_unix.sh>
>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
You received this message because you are subscribed to the Google Groups
"Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to neo4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
