"view" in cypher?

[Joe Zhang]

Dear list:

 

Is there a way to produce something equivalent to the SQL "view" in the cypher context?

 

Thanks!

 

Joe

[Andres Taylor]

Hi,

We've talked about adding it to Neo4j, but just loosely. It would be interesting to understand more about what you are trying to accomplish. Care to share?

Andrés

--
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+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Joe Zhang]

Yes.  The basic idea is the produce a subgraph, and then run some algorithm on top of the subgraph.

 

More specifically, what we need to is to compute a subgraph by filtering on certain properties of nodes and rels, then compute varisou shortest paths on the subgraph. This is not quite achieveable in the current neo4j, given that the built-in shortestpath function does not take much filtering.

[Wes Freeman]

Would solving the shortest path ability to filter solve your use case? There are plans for that.

Just to be pedantic (and FYI), I think you mean the current Cypher, because the Java API does let you filter pretty well, I've learned. If your use case requires fast shortestpath queries with filters you might want to check out an unmanaged extension until Cypher gets up to speed in that department, which is hopefully by 2.0 GA, what do you think Andres? :)

How about doing something with labels to simulate a view (maybe this could lead to some view-like implementation):

// create a subgraph with labels

match n-[r:Example*3]-m
where r.flag = 1 // just an example filter...

and n.name="a"
set m:Subgraph, n:Subgraph;

// then the question is how to use labels to effectively filter your query to use that subgraph

match p=n-[r*]-m:Subgraph
where all(x in nodes(p) | x:Subgraph) // ensure all nodes in path are part of the graph (this part isn't optimized yet--conditions looking at a path)

return p

order by length(p)

limit 1;

// get rid of the subgraph (optional)

match n:Subgraph 

remove n:Subgraph;

Wes

[Joe Zhang]

Thanks for your response, Wes. I have several responses:

 

1. Yes, making shortestpath capable of flexible filtering would solve my particular case --- When is that going to happen?

2. Regardless of my case, having the "view" is a great feature.

3. I put thoughts into the label-based solution (before and after your suggestion). My big concern is that the 2nd step is rather expensive, since it doesn't use a smart search algorithm (which is presumably implemented in the shortestpath function). What do you think?

[Wes Freeman]

Do you have some syntax ideas for views?

Responding do your #3, I agree. I just mentioned it as a possibility and tried to come up with a way to do it (albeit inefficiently). If cypher were optimized to both match and exclude path-oriented predicates as it matches a pattern, it might beat performance in cases where your graph is dense enough that the label is a small subset.

Wes

[Joe Zhang]

How about "create view as ... " ?

[Wes Freeman]

And then you query it by?

Wes

[Joe Zhang]

You got me :) How about something like:

 

creat view vname as .......

 

when you query:

 

start vname ....

[reza afzalan]

@Andres @Joe @Wes

Hi

I love this idea.

But I think a little bit different.

Wonder about a chemical material database, select e.g. methanol with a formula like: CH4O

Below U can see a different views of CH4O:

Here we have different kind of materials:

            1-Elements like: H (Hydrogen), O (Oxygen)

            2-Chemicals like: CH3, HO.

All the elements have a node with specific properties and graphics.

Chemicals may have a node with specific properties and a graphic that is a view of the others.

or may be only a conceptual view.

The important points about this kind of view is:

            1- it is an in memory, totally new arrangement of nodes & views.

            2- a node may have deferent locations in a view, so view constructor must have the ability to repeats a node in different locations.

            3-in this kind of view new relations between elements are created, so view constructor must have the ability to create in-memory relations between elements of view.

[Joe Zhang]

Interesting thought, Reza.

--

[John O'Gorman]

Long time since this was posted, but I was wondering if any more was done on it.  I have similar challenge and reza describes it very well by separating elements from compounds (chemicals).  Maybe one way to think of a view is by using the name of the compound 'Methanol' as the aggregate and equivalent representation of both the graphics and the graph.

[Michael Hunger]

There have been discussions about adding a "graph" concept to the property graph model which would entail: top-level-properties, nodes and relationships.

Then your chemical molecule would be a named graph "methanol" with the nodes and relationships but also the high level properties of this compound.

But so far nothing concrete yet.

You can simulate it by using additional node labels (or alternatively a "graph" array property on nodes or relationships which indicate which graph(s) they belong to)

And then a "root" node that holds the graph-properties of that graph.

HTH,

Michael

--

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+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.