collabrx / callisto Goto Github PK

The current model of doing get/get_or_create/create/update/delete for Vertex works fine, but you can query for "just a vertex".

Extending that to edges, though, is a problem. Although an edge can be returned by itself, and be represented as an Edge struct (with a type and properties hash), you can't actually query for edges "alone" -- you always have to bound them, at the very least as "()-[r]->()" which means you also can't actually create one without a full "triple" to go with it (unless you really want that edge to be duplicated between all nodes in your graph!)

I added a method "get_path" to help me deal with the question "does this path exist already, based on these finders", but it was a kludge to help get some work done. It feels like we should have a get_or_create function for Edge, but it would have to take more arguments, namely, the vertex matchers that the edge should go between. Ultimately, it would come down to "MATCH (x:Foo {}), (y:Bar {}) MERGE (x)-[r:isA {}]->(y) ON CREATE SET r += { id: '12345' } RETURN r, type(r)" -- but what should the elixir actually look like? Graph.get_or_create(path=%Triple{}, created_edge_props=%{}) ?

Maybe I'm over thinking it, but would love suggestions for how this should work. Should it just use the Triple we already have? or use pattern matching to allow for either a keyword hash that turns into a Triple, or what... Now that we have other people looking at the package and the code, I'm definitely keen to hear what others think.

I'll mention here a few things I found surprising about Query behavior. I consider these things bugs, but I can also see an argument being made that they are not (I don't know much about the existing conventions used in ecto, etc) If other people agree they are bugs I can make patches.

First quirk: pipe-lining with an individual query overwrites rather than appending.

iex(1)> %Query{} |> Query.merge("x")  |> Query.merge("y") |> to_string
"MERGE y"

I expected to see something like MERGE x\nMERGE y. I think appending makes more sense, but if that's undesirable then probably an error should be thrown instead of the silent overwrite. The workaround for the existing behavior often seems more verbose and cumbersome. For example:

q = %Query{} # empty query
cypher = [ Query.merge(q, "x"), Query.merge(q, "y")]
|> Enum.map(&to_string/1)
|> Enum.join("\n")

Second quirk. As in the code above, setting up an empty %Query{} is quite a common thing in my code. While Query.merge(%Query() , "x") formula is probably more idiomatic elixir it does seem very useful to add a Query.merge/1 function clause for bitstrings. In other words Query.merge("pattern") would have the empty %Query{} implied. Ditto for Query.match, etc. The current behavior is undefined, see trace below.

iex(5)> Query.merge("x")
** (UndefinedFunctionError) function Callisto.Query.merge/1 is undefined or private. Did you mean one of:

      * merge/2