I've been getting some strange results with a Neo4j database I made (version 2.1.0-M01). I have a graph with the following relationship:
Node[211854]{name : "dst"} <-[:hasrel]- Node[211823]{name : "src"}
I've confirmed this relationship using the following query:
START m=node(211854) MATCH (m)<-[r]-(n) RETURN m,r,n;
which returns a one row result, as expected:
| m | r | n
| Node[211854] | :hasrel[225081] | Node[211823]
The following query returns nothing, however:
START n=node(211823) MATCH (m)<-[r]-(n) RETURN m,r,n
Any thoughts on what might be happening? I've run these queries with and without indexes on the name properties for the nodes.
EDIT: Fixed typo with initial node number.
EDIT2: I rebuilt the server and both queries return the results I expect. Perhaps the error was corruption in the first database?
Using the node id's is not such a good idea, you can use the properties on your node to query them.
For example:
MATCH (m)<-[r]-(n {name: "src"}) RETURN m,r,n;
Does that query return what you expected?
You have to invert the relationship-direction. As you are looking for incoming relationships for your node 211823, this is not one of them. It's an outgoing relationship.
Please also update your database to the current version: 2.1.2 http://neo4j.org/download
START n=node(211823) MATCH (m)-[r]->(n) RETURN m,r,n
Perhaps you should give your nodes and relationships more descriptive names, so you spot easier when you inverted a domain concept.
Related
I have a highly interconnected graph where starting from a specific node
i want to find all nodes connected to it regardless of the relation type, direction or length. What i am trying to do is to filter out paths that include a node more than 1 times. But what i get is a
Neo.DatabaseError.General.UnknownError: key not found: UNNAMED27
I have managed to create a much simpler database
in neo4j sandbox and get the same message again using the following data:
CREATE (n1:Person { pid:1, name: 'User1'}),
(n2:Person { pid:2, name: 'User2'}),
(n3:Person { pid:3, name: 'User3'}),
(n4:Person { pid:4, name: 'User4'}),
(n5:Person { pid:5, name: 'User5'})
With the following relationships:
MATCH (n1{pid:1}),(n2{pid:2}),(n3{pid:3}),(n4{pid:4}),(n5{pid:5})
CREATE (n1)-[r1:RELATION]->(n2),
(n5)-[r2:RELATION]->(n2),
(n1)-[r3:RELATION]->(n3),
(n4)-[r4:RELATION]->(n3)
The Cypher Query that causes this issue in the above model is
MATCH p= (n:Person{pid:1})-[*0..]-(m)
WHERE ALL(c IN nodes(p) WHERE 1=size(filter(d in nodes(p) where c.pid = d.pid)) )
return m
Can anybody see what is wrong with this query?
The error seems like a bug to me. There is a closed neo4j issue that seems similar, but it was supposed to be fixed in version 3.2.1. You should probably create a new issue for it, since your comments state you are using 3.2.5.
Meanwhile, this query should get the results you seem to want:
MATCH p=(:Person{pid:1})-[*0..]-(m)
WITH m, NODES(p) AS ns
UNWIND ns AS n
WITH m, ns, COUNT(DISTINCT n) AS cns
WHERE SIZE(ns) = cns
return m
You should strongly consider putting a reasonable upper bound on your variable-length path search, though. If you do not do so, then with any reasonable DB size your query is likely to take a very long time and/or run out of memory.
When finding paths, Cypher will never visit the same node twice in a single path. So MATCH (a:Start)-[*]-(b) RETURN DISTINCT b will return all nodes connected to a. (DISTINCT here is redundant, but it can affect query performance. Use PROFILE on your version of Neo4j to see if it cares and which is better)
NOTE: This works starting with Neo4j 3.2 Cypher planner. For previous versions of
the Cypher planner, the only performant way to do this is with APOC, or add a -[:connected_to]-> relation from start node to all children so that path doesn't have to be explored.)
I'm writing a cypher query to load data from my Neo4J DB, this is my data model
So basically what I want is a query to return a Journal with all of its properties and everything related to it, Ive tried doing the simple query but it is not performant at all and my ec2 instance where the DB is hosted runs out of memory quickly
MATCH p=(j:Journal)-[*0..]-(n) RETURN p
I managed to write a query using UNIONS
`MATCH p=(j:Journal)<-[:BELONGS_TO]-(at:ArticleType) RETURN p
UNION
MATCH p=(j:Journal)<-[:OWNS]-(jo:JournalOwner) RETURN p
UNION
MATCH p=(j:Journal)<-[:BELONGS_TO]-(s:Section) RETURN p
UNION

MATCH p=(j:Journal)-[:ACCEPTS]->(fc:FileCategory) RETURN p
UNION
MATCH p=(j:Journal)-[:CHARGED_BY]->(a:APC) RETURN p
UNION
MATCH p=(j:Journal)-[:ACCEPTS]->(sft:SupportedFileType) RETURN p
UNION
MATCH p=(j:Journal)<-[:BELONGS_TO|:CHILD_OF*..]-(c:Classification) RETURN p
SKIP 0 LIMIT 100`
The query works fine and its performance is not bad at all, the only problem I'm finding is in the limit, I've been googling around and I've seen that post-processing queries with UNIONS is not yet supported.
The referenced github issue is not yet resolved, so post processing of UNION is not yet possible github link
Logically the first thing I tried when I came across this issue was to put the pagination on each individual query, but this had some weird behaviour that didn't make much sense to myself.
So I tried to write the query without using UNIONS, I came up with this
`MATCH (j:Journal)
WITH j LIMIT 10
MATCH pa=(j)<-[:BELONGS_TO]-(a:ArticleType)
MATCH po=(j)<-[:OWNS]-(o:JournalOwner)
MATCH ps=(j)<-[:BELONGS_TO]-(s:Section)
MATCH pf=(j)-[:ACCEPTS]->(f:FileCategory)
MATCH pc=(j)-[:CHARGED_BY]->(apc:APC)
MATCH pt=(j)-[:ACCEPTS]->(sft:SupportedFileType)
MATCH pl=(j)<-[:BELONGS_TO|:CHILD_OF*..]-(c:Classification)
RETURN pa, po, ps, pf, pc, pt, pl`
This query however breaks my DB, I feel like I'm missing something essential for writing CQL queries...
I've also looked into COLLECT and UNWIND in this neo blog post but couldn't really make sense of it.
How can I paginate my query without removing the unions? Or is there any other way of writing the query so that pagination can be applied at the Journal level and the performance isn't affected?
--- EDIT ---
Here is the execution plan for my second query
You really don't need UNION for this, because when you approach this using UNION, you're getting all the related nodes for every :Journal node, and only AFTER you've made all those expansions from every :Journal node do you limit your result set. That is a ton of work that will only be excluded due to your LIMIT.
Your second query looks like the more correct approach, matching on :Journal nodes with a LIMIT, and only then matching on the related nodes to prepare the data for return.
You said that the second query breaks your DB. Can you run a PROFILE on the query (or an EXPLAIN, if the query never finishes execution), expand all elements of the plan, and add it to your description?
Also, if you leave out the final MATCH to :Classification, does the query behave correctly?
It would also help to know if you really need the paths returned, or if it's enough to just return the connected nodes.
EDIT
If you want each :Journal and all its connected data on a single row, you need to either be using COLLECT() after each match, or using pattern comprehension so the result is already in a collection.
This will also cut down on unnecessary queries. Your initial match (after the limit) generated 31k rows, so all subsequent matches executed 31k times. If you collect() or use pattern comprehension, you'll keep the cardinality down to your initial 10, and prevent redundant matches.
Something like this, if you only want collected paths returned:
MATCH (j:Journal)
WITH j LIMIT 10
WITH j,
[pa=(j)<-[:BELONGS_TO]-(a:ArticleType) | pa] as pa,
[po=(j)<-[:OWNS]-(o:JournalOwner) | po] as po,
[ps=(j)<-[:BELONGS_TO]-(s:Section) | ps] as ps,
[pf=(j)-[:ACCEPTS]->(f:FileCategory) | pf] as pf,
[pc=(j)-[:CHARGED_BY]->(apc:APC) | pc] as pc,
[pt=(j)-[:ACCEPTS]->(sft:SupportedFileType) | pt] as pt,
[pl=(j)<-[:BELONGS_TO|:CHILD_OF*..]-(c:Classification) | pl] as pl
RETURN pa, po, ps, pf, pc, pt, pl
i just encountered an odd behaviour in neo4j
when i run this query
match (n)-[rel:HAS_A|HAS_DIPNOT *]->(c) where id(n) = 9457 return c
it returns expected nodes and relations..
however when i run this:
match (n)-[rel:HAS_DIPNOT *]->(c) where id(n) = 9457 return c
it returns nothing as can be seen on the screen capture..
do you have any idea why this happens?
Which relationships does the node with id 9457 have?
I presume it only has :HAS_A relationships. So your second query cannot traverse out the single step needed until there are :HAS_DIPNOT to continue on.
The nodes you highlighted have other id's.
I'm playing around with neo4j community edition 2.0.1, and I've struck a problem which I can't find a solution to. My ineptitude with Cypher may be contributing to my issues!
I have a small number of nodes, with an index on a "Name" property. For demonstration purposes, I have two nodes "Foo" and "Foo Bar". Running any of the following Cypher queries in the browser interface works fine - returning either one or both nodes:
START n=node:node_auto_index("Name:Foo") match n RETURN n
START n=node:node_auto_index("Name:Foo*") match n RETURN n
However, running the following query returns a Neo database error (Neo.DatabaseError.Statement.ExecutionFailure) - note the space in the name:
START n=node:node_auto_index("Name:Foo Bar") match n RETURN n
I'm at a loss as to what this issue might be - is this an error with my search request, or a known problem with the database? Many thanks!
The string supplied to node:node_auto_index is passed directly to the index provider (which is Lucene by default). There Lucene query syntax applies, see: http://lucene.apache.org/core/2_9_4/queryparsersyntax.html.
Space is a term separator in your case, so you might try:
START n=node:node_auto_index("Name:'Foo Bar'") match n RETURN n
(Actually - it's as per Stefan's comment below:
START n=node:node_auto_index('Name:"Foo Bar"') match n RETURN n
Thanks Stefan!)
I'm beginner about neo4j and I'm evaluating neo4j version 2.0.0 RC1 community edition.
I tried to delete a node from one million nodes using browser interface(i.e host:7474/browser/)
Even though match query without delete clause works fine, match query with delete return Unknown error.
The following query working fine and fast response
match (u:User{uid:'3282'}) return u
The delete query returning Unknown error
match (u:User{uid:'3282'}) delete u return u
The node labeled User contains one million nodes, so I guessed Unknown error is because of slow performance.
Also, setting property query return unknown error in like fashion.
Is it usual neo4j's write performance? Is there a way to resolve the problem?
Thanks
I believe the issue is that you're trying to return the node that you just deleted. You can delete without the return, which should work fine:
match (u:User{uid:'3282'}) delete u;