Querying and constructing multiple graphs #241
Conversation
This covers a lot of ground: * Data model * Language execution model * Working with named graphs * Declarative Graph Construction * Graph composition * New Patterns: Optional Copy Patterns * New Patterns: Merge Patterns * Create, update, modify persistent graphs
boggle
force-pushed
the
CIP2017-06-18-multiple-graphs
branch
3 times, most recently
from
2498907
to
7332c02
Compare
boggle
force-pushed
the
CIP2017-06-18-multiple-graphs
branch
from
7332c02
to
8459014
Compare
boggle
force-pushed
the
CIP2017-06-18-multiple-graphs
branch
from
8459014
to
4714ca6
Compare
| === (Property) Graph | ||
|
|
||
| _Definition_ A *property graph* is a set of labeled nodes and typed relationships both together with their properties (a property is a tuple of a named key and a value). | ||
| Graphs may be updatable, i.e. the set of contained nodes and relationships may change during the lifetime of the graph. |
There was a problem hiding this comment.
This section should probably link to the PGM spec in our repo.
| It is an error to attempt to update a read-only graph. | ||
|
|
||
| The same node or relationship may be part of many graphs. | ||
| A relationship may only be part of a graph if it's start node and it's end node are both also part of the same graph. |
There was a problem hiding this comment.
it's -> its
or rephrased:
if its source and target nodes are both also ...
There was a problem hiding this comment.
That always trips me up :)
There was a problem hiding this comment.
Yeah, used to trip me up too, but then I learned that it's == it is, so in case you're unsure, just spell it out and it'll become apparent :)
|
|
||
| The same node or relationship may be part of many graphs. | ||
| A relationship may only be part of a graph if it's start node and it's end node are both also part of the same graph. | ||
| Therefore removing a node from a graph may require removing some of it's relationships from the graph, too. |
There was a problem hiding this comment.
it's -> its
It not only may, it will require removing all of them. Or rephrased:
Thus, removing a node from a graph will require removing all of its relationships from that graph, too.
|
|
||
| Graphs do not expose an identity like nodes or relationships do. | ||
|
|
||
| Graphs may be made addressable through other means by a conforming implementation (e.g. through exposing the graph under a _graph URL_ for referencing and loading it). |
There was a problem hiding this comment.
I suggest unwrapping the example from parentheses.
|
|
||
| With this terminology in place, execution of a parameterized Cypher query in the single graph execution model can be described as executing within (and operating on) a given execution context and an initial query context and finally returning the query context produced as output for the top-most `RETURN` clause. | ||
|
|
||
| Note: This formulation is introduced to describe a high-level model for the execution of queries; A real world implementation is free to choose any other internal representation (e.g. based on an algebra) as long as it does not violate the specified semantics. |
| * `<graph-specifier-list>`: A comma separated list of `<graph-specifier>` that are to be passed on | ||
| * `*`: All named graphs are to be passed on | ||
| * `*, <graph-specifier-list>`: All named graphs are to be passed on together with any additional named graphs that are newly bound in `<graph-specifier-list>` | ||
| * `-`: No named graphs are to be passed on |
There was a problem hiding this comment.
I'm interpreting that GRAPHS is optional (which I support). What is the point of GRAPHS - if we can just leave it out?
| This in essence mirrors the semantics for tabular data returned by Cypher. | ||
|
|
||
| Both `WITH ... GRAPHS ...` and `RETURN ... GRAPHS ...` will pass on (or return respectively) exactly the set of described named graphs. | ||
| To simplify passing on available graphs it is proposed by this CIP that regular `WITH <return-items>` is taken to be syntactic sugar for `WITH <return-items> GRAPHS -` and that regular `RETURN <return-items>` is taken to be syntactic sugar for `RETURN <return-items> GRAPHS -`. |
There was a problem hiding this comment.
What is the point of having a long-form GRAPHS - as the normal form, and call leaving it out syntactic sugar? Why not say that leaving it out is the normal form, and that the other forms modify that?
There was a problem hiding this comment.
The procedures CIP (?) I think added - for procedures not returing any columns, similarly researches have suggested, that it is an omission on the part of SQL to not be able to return no columns (more so for Cypher where the single row field less table plays a special role to start off queries). In light of this I added this for no reason but consistency with these other decisions.
There was a problem hiding this comment.
But for procedures there was actually a need for YIELD - in order to not cause implicit conflicts with variables that were in scope, as I recall. My personal preference would be to use the empty string to denote the intention in this proposal.
| Both `WITH ... GRAPHS ...` and `RETURN ... GRAPHS ...` will pass on (or return respectively) exactly the set of described named graphs. | ||
| To simplify passing on available graphs it is proposed by this CIP that regular `WITH <return-items>` is taken to be syntactic sugar for `WITH <return-items> GRAPHS -` and that regular `RETURN <return-items>` is taken to be syntactic sugar for `RETURN <return-items> GRAPHS -`. | ||
|
|
||
| To even further simplify, it is additionally proposed that `WITH|RETURN <return-items> INPUT GRAPHS <graph-return-items>` is to be syntactic sugar for `WITH|RETURN <return-items> GRAPHS <graph-return-items>, SOURCE GRAPH, TARGET GRAPH`. |
There was a problem hiding this comment.
I'm not convinced of the usefulness of this syntactic sugar -- I find that it is hard to know what kind of queries will be prominent in this new model. In general, I think that it would be useful to have a little less focus on the syntactic sugar bits, and more on the core model. Syntactic sugar additions could always follow later.
There was a problem hiding this comment.
Let's revisit how default graphs are handled as a group first - this may very well remove the need for this. In short I added this as a simple way for a query to say: "I'm ok to run on any incoming graphs and am happy to pass those on, just give 'em some names for me". Without this sugar, expressing this becomes rather verbose.
There was a problem hiding this comment.
I'm not against the sugar per se, I just find it difficult to assess whether a particular piece of sugar is valuable this early in the process of defining these very new concepts, and so I'm leaning towards skepticism in general. I find it is peripheral to the contents of the CIP anyway.
|
|
||
| === Discarding available tabular data | ||
|
|
||
| It is additionally proposed that both `WITH GRAPHS <graph-return-items>` and `RETURN GRAPHS <graph-return-items>` are syntactic sugar for `WITH - GRAPHS <graph-return-items>` (and `RETURN - GRAPHS <graph-return-items>` respectively). |
There was a problem hiding this comment.
I feel similarly to this as to GRAPHS -; I prefer the absence of - to its presence in this context.
|
|
||
| However, the change has been carefully designed to not change the semantics of existing queries. | ||
|
|
||
| == Alternatives |
There was a problem hiding this comment.
I think this and subsequent sections are superfluous since the introduction of CIRs. We should modify our template.
|
Great work putting these concepts into spec! |
- Homogenized graph specifier syntax - Added DEFAULT GRAPH - WITH, RETURN can also return comma separated list of graphs without leading `GRAPHS` if bound graphs are prefixed with `GRAPH`, i.e. RETURN a, b, c COPY OF GRAPH foo is possible
- COPY .. TO .. - Allow FROM <name> AS <new-name> (wo leading GRAPH) - Allow INTO <name> AS <new-name> (wo leading GRAPH)
petraselmer
force-pushed
the
CIP2017-06-18-multiple-graphs
branch
2 times, most recently
from
54286fa
to
b402f1d
Compare
- The jpg files ought to be moved elsewhere at a later stage
petraselmer
force-pushed
the
CIP2017-06-18-multiple-graphs
branch
2 times, most recently
from
335a474
to
3258b3b
Compare
…le/openCypher into CIP2017-06-18-multiple-graphs-devel
boggle
force-pushed
the
CIP2017-06-18-multiple-graphs
branch
from
7f258be
to
c5b8e42
Compare
boggle
added
oCIG
cypher10
boggle
changed the title
|
hi all, I have read your documentation. I found it easy to mix
and
suppose the working graph is yyy, is it both two cyphers will lead to create nodes with a label Thanks for your reply. |
This is a proposal for making Cypher work with multiple graphs.
It is part of the redesign of Cypher for adding support for working with multiple graphs that targets Cypher 10.
View latest version of CIP from associated branch