Full schema counts filtered from perspective of a node

Hi community! I am trying to return a query result (either cypher or apoc) which will return schema counts (nodes and relationships) based on the perspective of a specific node. I want to create a query that will return counts for every distinct node and edge type, without explicit naming of path or node types, outside of the node type and property:value I want to filter by.

One of the node types has a property I want to filter the rest of the database by. The directionality of the paths is not one way, and some of the nodes have relationships with many node types (paths are not like spiderlegs hinging off the filterable node). Interested in something like “CALL apoc.meta.stats” that is filterable by (as an example) (n:Person {name:’Gertrude’}). I don’t want to count a node or relationship more than once. I want to expose the results via an api I can present dynamically in a web page. I have tried unwind, but the number of hops in any given path is unpredictable. I want the query to work even if new node and relationship types are added.

Thanks to you who have read this and thanks to anyone who has an idea on how to solve this.

I am trying to create a visualization that shows each node and edge along with the counts of each from the perspective of the filtered node.

@sonjar4ai

Not sure I completely understand but one can run

and for v5.x forward syntax ( are you running v5? or v2025? if not what version )

each node in the graph has metadata associated with the node which describes

# of relationship 
# of relationships by type
# of relationship by type and direction

Note the metadata does not include data on by type and direction and destination label

To access this metadata one can run

match (n:Person {name:'Gertrude'} ) 
return
count {  (n)-[r]-() } as CountAllRels,
count {  (n)-[r]->() } as CountAllOutgoingRels,
count {  (n)<-[r]-() } as CountAllIncomingRelse

this query should be really fast in that it simply finds the :Person node with name:’Gertrude’ and then accesses the underlying metadata. It does not need to iterate over each and every relationship hung from this node.

If you take this query and preface the query with PROFILE you will see numerous references to

getDegree((n)<--()) AS .... ....

this getDegree is telling you that it is accessing the metadata.

Hi @dana_canzano . Firstly, thank you so much for taking the time to respond. I tried the queries you suggested, and the challenge I have is that the paths aren’t variable in length. I am running desktop 2.0.1. I created a data model with expected counts that I think illustrates my problem. I am trying to create a similar diagram based on a drop-down filter in my UI. The dropdown filter would be populated with names of the Person node. The challenge is the traversals. I ultimately want to show the population of nodes where Gertrude directly is impacted. I also know that my data model will grow over time as more entity types come into the picture. I am trying to figure out the best way to:

  1. Be filterable by person name (in case I want to query for Ravi instead)
  2. Create a query that will accomodate the incorporation new node types over time
  3. Count distinct nodes, regardless of the traversal path or direction (and capture all node types with distinct counts)
  4. Count distinct relationships (and capture all relationship types with distinct counts)
  5. Not loop back and count Gertrude
  6. Not be limited by one path (for example, I don’t want only the 20 Quests SUPPORTED_BY Shops, but all 42 Quests.)

In my mind there is a process that maps all hops, without repeating a node, as I highlighted around the domicile and without needing to explicitly name the path. If I traverse via the Quest count - I would get 5 domicile, but if I traversed via Gertrude’s residency, I would get a count of 1. I want to capture the 5 distinct domiciles. If I used the query you suggested

count { (n)-[r]-() } as CountAllRels, and am thinking about how to union with multiple hops, but I also want the node types with the counts…so still figuring that out.

All this said, I don’t want to hose my db by doing a scan of each row of the table.