abstractions for node/relationships about neo4j_sips HOT 24 CLOSED

FYI, went with Apache 2.0 licensing. 👍

from neo4j_sips.

I was indeed thinking about adding the support for Nodes and Relationships, but I wasn't able to find the time yet. PRs are more than welcome, of course :)

from neo4j_sips.

Cool, well if you have specific ideas and time to write them down then I'll be happy to implement it.

If on the other hand you have no specific ideas.. I'll start improvising later today (this is only one piece of a toy project I had in mind and I'm impatient ;)

from neo4j_sips.

awesome. Honestly, I dedicated a lot of time on this topic, on the other project; https://github.com/florinpatrascu/neo4j_sips_models, see the support for Nodes and Relationships. However, for the neo4j_sips, we should have a straightforward implementation, as in just simply following the Neo4j API for Ns and Rs, so that it can allow others to add more high level functionality in their custom implementations if they need so. Give it a try, if you find some time.

from neo4j_sips.

My team at CollabRx are working on some code for the struct/hash-to-Cypher-and-back pattern. Give me a day or two and I'll point you at it and we can see where it needs to go from there.

from neo4j_sips.

Nice! Thank you, all :)

from neo4j_sips.

It's very, very, very much alpha code, WIP stuff, but if you want to see what we're toying with, take a look at CollabRx/callisto No guarantee it'll look anything like it does now, tomorrow -- I've been refactoring and rewriting a lot as we go.

from neo4j_sips.

Thank you, Paul!

from neo4j_sips.

A little off topic for this repo, but since we're all chatting here.. what is the status of relationship support in neo4j_sips_models? Is it actually working or just sketched out? I noticed these tests are really just confirming metadata on model objects. I tried using something like Person.update(alice, family_member: [bob, charlie]) and then re-retrieving alice, but I don't see any edges on either the object instance or the webui. Is it failing silently with the list?

Callisto looks interesting, but given API instability maybe it's simplest if I just solve my problems using the REST API. As a test I bolted functions like this on to Person:

  def node_url(node) do base_url() <> "/db/data/node/#{node.id}" end

  def base_url() do Application.get_all_env(:neo4j_sips)[Neo4j][:url] end

  def relationships_url(node) do node_url(node) <> "/relationships" end

then adding a link between Person's is as simple as

  def link(alice, bob) do 
    json = %{to: Person.node_url(page), type: "links_to"} |> Poison.encode!
    HTTPoison.post!(Person.relationships_url(alice), json)
  end

I'm new to neo4j but as I skim callisto and neo4j_sips source, it seems to me you guys are building nodes/edges with cypher queries. Raw cypher is obviously necessary for queries and such, but is there a reason to do CRUD stuff this way?

from neo4j_sips.

The update function for the Relationships, was not finished in neo4j_sips_models, sorry. I started to refactor the neo4j_sips_models with the hope that I can bring it up to a level where it can act as an Ecto driver but then the callbacks were removed from Ecto, and I lost my direction a bit. You can create relationships, but you can't update them ... I know .... I should probably mark neo4j_sips_models as experimental, not to confuse the users, tho it works well in some scenarios.

Callisto looks very interesting, indeed. I wish it was around few months ago :)

In neo4j_sips, I wanted intentionally to let the cypher queries flow to the server undisturbed and to bring back just basic structures, reducing this way any future frictions between the neo4j_sips and a higher level implementation. I do indeed see the need to add the support for the Nodes and Relationships, at least for covering the entire Neo4j API. I started to look at implementing the Bolt connectivity but now I see somebody else was faster: https://github.com/mschae/boltex, therefore I'll focus on adding more low level support in neo4j_sips, covering this way the remaining Neo4j API.

from neo4j_sips.

Started last night to mock Nodes and Rels. from scratch; not planning to reuse code from the neo4j_sips_models. Will be fun :)

I was also looking at Callisto and there are a bunch of goodies I could use right away, i.e. properties. The only support I'd probably stay away from, is the Callisto.Cypher; it's probably me, just being too cautious.

@dotdotdotpaul, what license are you guys planning to use, for Callisto? Not sure how I'll integrate it, ideally using it as a whole?! I'll start using the properties first, for the Nodes :)

from neo4j_sips.

It's all a work in progress, I hadn't thought about the license yet. There's no real "IP" going into this, so I'm thinking your basic license as any other open source library -- What's the latest hotness, GNU license? MIT? Something newer? :)

Callisto.Cypher is an attempt to layer over the construction of Cypher queries, in a similar way to how ActiveRecord/Arel attempts to insulate from SQL -- with limitations, of course.

from neo4j_sips.

Merged a big chunk o' progress into Callisto, updated the README to start giving some idea of where we're going with it. I think it's actually usable with Neo4j.Sips now, at least for passing MATCH queries through -- although I haven't documented how to get the configuration completely set up. ;)

I'm in the process of converting the application code we had "mostly working" before to use the new hotness, so I'll be fleshing out a lot of the create/update/delete functionality as I get that going.

Callisto.Cypher is currently just a holding pot for common things that convert data into Cypher (like escaping strings properly, the syntax for properties, etc). Callisto.Query is a structure to act as a composable query entity, so you can pass "part" of a query around and then finish it later (for example, if you want to retrieve the same data over and over, but change up the WHERE clause or something). Query knows of the Vertex and Edge structs, so if you pass those in, they can be automagically converted into the "matcher" pattern used in Cypher.

I've only been doing Elixir "seriously" for the last month or so, so I'm sure I'm doing something wrong or inefficiently -- feel free to toss me tickets on the GitHub project if you've got suggestions or bug reports! :)

from neo4j_sips.

you were right when you said you're prepping code that may smooth out the Nodes/Rels implementation :) Now I see it and I'll start using it. The README you have is also helpful, thank you for that too.

Initially I thought I should use just the parts I need, from Callisto, but the more I dive into its code the more I need from it, so I'll use it as is and I'll post my findings or PRs in Callisto's own repo.

One thing that transpires from what Callisto could do, is the Ecto aroma :) And I said I won't transform neo4j_sips into an Ecto driver ... but with Callisto, I should probably rethink my previous statements ... darn .. now I need time.

I've been doing Elixir for a bit more than half an year now, so no, I'm not that advanced either; still earning my bread from Java and Ruby, but I'll gladly contribute to Callisto on my way to integrating it in neo4j_sips. Thanks again, @dotdotdotpaul!

__
BTW, re License, is up to you of course, I am using MIT or Apache (combined with the Neo4J one, where applicable) fwiw

from neo4j_sips.

If you come up with a good way to drive Ecto-like behavior with Cypher/Neo4j, definitely let us know on Callisto. We actually started out that way, we had internal structs with "schemas" and then macro'd things like ".get()" and ".create()" onto the actual structs (so you could do "Foo.create(%{})" and it would basically call Vertex.create(Foo, %{}). We can definitely still do that... BUT! We ran into cases where we actually needed/wanted those records to have more than one label. That could be solved by having the labels be a list, still, defined on the struct through properties, but then the labels-as-validators isn't as composable. So our first goal is to get un-macro'd Vertex and Edge working well, and then we can perhaps go back to having macros for those "instances" that can act as data containers.

Then there's that nasty problem where when you get nodes back from Cypher, you can have a complete mix of labels (depending on your search), and we'd have to figure out how to convert from a set of string labels coming back from Neo4j to the appropriate struct type (which could be difficult if the struct type is actually two different labels). Anyways, those are the things I figure I'll solve as our app gets to them. :)

from neo4j_sips.

Hey @dotdotdotpaul - I spent this weekend tinkering at Callisto and continued the development for the Neo4j adapter; using the .. new Neo4j,Sips ;) I have a very basic demo at: https://github.com/florinpatrascu/callisto_demo, using a forked Callisto and the new development branch of Neo4j.Sips. I didn't send a PR b/c I wasn't sure where you guys are at, with the plans for the adapter?! Please have a look at this branch: tinkering_at_adapters, in my Callisto fork, and I can send the PR if you guys like it. Anyway, now Callisto has supervised repos, ala Ecto, and a new shiny adapter for Neo4j.Sips. This is a first iteration, as I need to do more for the logging support and such, but probably next weekend or in the days to come, if I can find some time in the evenings. BTW I'm reusing this issue, because I could't create one in the main Callisto repo, sorry for the off topic. I'll go catch up with rest of the weekend :)

Cheers!

from neo4j_sips.

I (think) I enabled issues on the project -- didn't realize I had to enable it separately.

We/I haven't done much of anything with the whole Adapters bit, our focus has been just to get stuff working with Neo4j.Sips which we're already working with. We'd be completely stoked to merge it. I did a quicky-quick inspired-by-Ecto job on adapters to try to connect the final dots between Callisto and Neo4j, but wasn't really sure how much Neo4j "smarts" needed to go into Callisto, and how much I could/should leave to Neo4j.Sips. As you're the current Neo4j expert, I'm happy to have you flesh out the adapter side of things. :)

The demo makes it all look so simple. :)

from neo4j_sips.

Ah, then I am glad to help :) Just sent the PR.

In order to use the Callisto Neo4j Repo :) please use the Neo4j.Sips from the act_as_adapter branch, until I can publish the latest version to hex, probably later today or tomorrow evening. Sorry for this inconvenience. Apparently mix is lagging and it is not updating the deps, when using the github :branch option :( Maybe is just my local tho' I doubt, but if it is happening to you as well, then pull the branch in a local neo4j_sips repo and use :path instead, in mix.exs. Meanwhile I'll watch the Callisto repo for issues ;)

from neo4j_sips.

(oh, you can enable the Logger now (Logger.level :debug), and catch what we send to the Neo4j server. It's not much in it for now, but it is better than tailing the neo4j server logs)

from neo4j_sips.

Awesomesauce. I might wait for the acts_as_adapter branch to get published before doing the final merge, then the pull request won't have any funky branch requirements. :)

from neo4j_sips.

done. New version available in master and at Hex.pm :)

from neo4j_sips.

I thought I'd update this thread with some news, in relation to the Nodes (Ns) and Relationships (Rs).

Last week-end I started to implement core support for Ns and Rs. BTW, since Node is an Elixir module, I believe I have an idea why @dotdotdotpaul is using Vertex for the node representation, in Callisto ;) Anyway, for my implementation I decided to use the less intimidating name for vertices: Node .. with the caveat of making sure that when we alias it, it should not to collide with the Elixir's own Node module)

So, as I was saying, the Node raw support is coming nicely along and it is using the Neo4j REST API support, excerpt from the tests passing so far:

 test "new node missing labels and properties" do
    assert %{id: _id, labels: [], properties: %{}} = Node.new
  end

  test "new node with a label from a string will have the label capitalized" do
    node = Node.new("person")
    assert %{id: _id, labels: ["Person"], properties: %{}} = node
  end

  test "new node with multiple labels will have all of them capitalized" do
    node = Node.new(["person", "human"])
    assert %{id: _id, labels: ["Person","Human"], properties: %{}} = node
  end

  test "create a node w/o properties, then delete it" do
    node = Node.create(Node.new)
    assert %{id: _id, labels: [], properties: %{}} = node
    refute node.id == nil
    assert :ok = Node.delete(node)
  end

and so on.

Now, I was about to move to implementing the support for Rs and had the inspiration to ask on Slack about some REST API functions I believe they would be nice to have. Instead, I got some important message, please check this thread: https://neo4j-users.slack.com/archives/drivers/p1469797134000017, in case you have access to Slack. The gist of it is:

chris.graphaware [9:07 AM]
The Cypher http transactional endpoint will remain for a while, I don’t know for the others but really, don’t use it !!!

So now I have to find out if I still go for using the REST API for Ns/Rs related functionality, or go for the Cypher endpoint (which BTW is at the core of the current Neo4j.Sips implementation, so at least the driver is safe, from this perspective).

Callisto, will probably do exactly that, manipulate Ns and Rs with Cypher, and for that I don't need to do much in Neo4j.Sips other than making sure the Callisto adapter for Neo4j(.Sips) is sound. But if the users want something more ... low level, i.e. abstractions for node/relationships( /cc @mattvonrocketstein ), then w/o continuing to implementing the Neo4j REST API in Neo4j.Sips they will either have to: use Callisto, or: I'd have to import Callisto in Neo4j.Sips .. the later is not a clean solution since Callisto itself may import Neo4j.Sips, as an adapter, if needed.

So, I am in a .. contemplative mode, now ... :)

Probably I'll continue this week-end to continue working on the few low-level bits for supporting at least the minimum Ns/Rs via the REST calls, but I am not sure where to go now.

Thoughts?

from neo4j_sips.

(not completely off-topic) After learning these past days more about the various aspects related to the future of the Neo4j (HTTP) REST API, I decided to refactor the connectivity in Neo4j.Sips and use Bolt instead. This will be available in Neo4j.Sips 0.3.x., while 0.2.x will continue to use the HTTP.

0.3.x will implement the db_connection behavior and will play nicely (even nicer ;)) as an adaptor or as a future Ecto compatible Neo4j driver.

I am closing this issue, as the Ns and Rs will be managed via Callisto, most probably, or with Cypher queries directly. Both Neo4j.Sips versions, 0.2.x and 0.3.x, are designed for the ability to send Cypher queries to the server.

from neo4j_sips.

Just published the Bolt.Sips; A(nother) Neo4j Elixir driver wrapped around the Bolt protocol, this time =) Please take a look at: https://github.com/florinpatrascu/bolt_sips, and let me know what you think.

Neo4j.Sips will continue forward with using Neo4j's HTTP REST API while Bolt.Sips will focus on using the Bolt network protocol.

from neo4j_sips.