domvas

domvas

Hello,
I’m pleased and a bit proud to present you seraph a library to define schema and query Neo4j database.

Again?
Yes again…
Since I’ve started Elixir, I’ve seen here and there attempts to develop a library to use Neo4j nicely, and even an adapter to Ecto… released by me.
But nothing was satisfying enough and ecto_neo4j was, and is still, a big disappointment. ecto is relational database oriented, and there is more or less only one entity is this case: table. But when it comes to graph, you have two entities: node and relationship. Then all I’ve done with ecto_neo4j was to force this two entities and graph concepts into a relational shape. Code became awful because of hacks everywhere, usage was limited and so restricted that you can’t model you graph database as you wish.
Then I drop this project and start seraph.

seraph is heavily inspired by ecto because using ecto to work with database is joy. And I tried to bring this joy to Neo4j graph database.
It’s still the beginning, a LOT is missing but it’s a first (good?) step for a nice library to work with Neo4j with schema, nice query api, etc.

Hope you’ll enjoy it.

Testers and contributors

Because of the amount of work, help would be appreciated, so if you want to test, to add some features, write some docs, please do!

So, quickly, what you can do if you don’t want to read the docs.

Schema

a node schema is like this:

defmodule GraphApp.Blog.User do
  use Seraph.Schema.Node
  import Seraph.Changeset

  alias GraphApp.Blog.User
  alias GraphApp.Blog.Relationship
  alias GraphApp.Blog.Relationship.NoProperties

  node "User" do
    property :firstName, :string
    property :lastName, :string
    property :email, :string
    
    # You can define two relatinship with same type but pointing to different node
    # without problem
    outgoing_relationship("WROTE", GraphApp.Blog.Post, :posts, Relationship.Wrote,
      cardinality: :many
    )

    outgoing_relationship(
      "WROTE",
      GraphApp.Blog.Comment,
      :comments,
      NoProperties.UserToComment.Wrote,
      cardinality: :many
    )
    
    # A relationship can ends to the same node it starts 
    outgoing_relationship(
      "FOLLOWS",
      GraphApp.Blog.User,
      :followed,
      NoProperties.UserToUser.Follows,
      cardinality: :many
    )
  end

# classic changeset
  def changeset(%User{} = user, params \\ %{}) do
    user
    |> cast(params, [:firstName, :lastName, :email])
    |> validate_required([:firstName, :lastName, :email])
  end
end

a relationship schema:

defmodule GraphApp.Blog.Relationship.Wrote do
  use Seraph.Schema.Relationship

  @cardinality [outgoing: :one, incoming: :many]

  relationship "WROTE" do
    start_node GraphApp.Blog.User
    end_node GraphApp.Blog.Post

    property :when, :utc_datetime
  end
end

Atomic operation with Repo.*

Each entity has its Repo.* functions:

  • get
  • get_by
  • set
  • create

Query DSL

And you can write nice queries with the query api.

import Seraph.Query

query = match [{u, User}],
  where: [u.firstName == "John"],
  return: [u]

GraphApp.Repo.all(query)

----

match([
    {u, GraphApp.Blog.User, %{firstName: "Jim"}},
    {u2, GraphApp.Blog.User, %{firstName: "Jane"}},
    [{u}, [rel, GraphApp.Blog.Relationship.NoProperties.UserToUser.Follows], {u2}]
]) 
|> delete([rel]) 
|> GraphApp.Repo.execute()

Showing Posts 1 to 7

josefrichter

josefrichter

oh god I wish I had a nice project to use with neo4j. it must be fun using it!

swelham

swelham

Great work! I have been wanting this to exist for some time but never been able to get around to building it myself. I have some initial thoughts listed below that came to mind whilst looking through the guides and I will definitely be looking to contribute where I can.

  • Support a non global config. Allow the config to be specified per instance of Repo in the supervision tree. This provides more flexibility and if the user wants a global config they can still do it.
  • Default datetimes to utc_datetime_usec. I believe this plays better with Elixir’s datetime module (no need for Datetime.truncate everywhere) and I seem to remember reading that the ecto core team wish they did this but now can’t due to backwards compatibility.
  • Support having snake case schema fields. I see the rational in enforcing camel case but as it’s not idiomatic Elixir it will end up forcing some inconsistency in the user’s application. This seems more like a db implementation detail and I think it should be possible to support snake case fields and then convert to camel case in the queries when dealing with the db.

But honestly it’s looking really good so far!

domvas

domvas OP

Thank for the kind words! It makes me think that the package is useful :sweat_smile:

What is the goal? Having the ability to connect / disconnect from database at runtime?
In fact, this update is quite trivial and can (will) be added.
Keep in mind that multi-tenancy is already supported and that in Neo4j, you can manage multiple databases on the same server (Database administration - Operations Manual)

Noted.
I haven’t implement the timestamps macro so it will be with utc_datetime_usec.
In fact, the date format in Neo4j is converted to datetime with microseconds in Elixir so I already get bitten when I used utc_datetime for the example :slight_smile:

I think you’re not going to be the last to have remarks on this point.
In any case, there’s a tradeoff:

  • CamelCase enforcing → atom with uppercase are not idiomatic (except for modules…) but valid.
  • snake_cased + conversion → you have to switch when you are writing query with seraph or writing query in pure cypher and this can be subject to errors
  • snake_cased without conversion → it’s not what’s recommended for Neo4j
    One in all, the best thing I can do is to implement all 3, defaulting to CamelCased and add config options to let each user decide what he prefers
swelham

swelham

Yeah, it’s definitely useful :smiley:

The goal is more about flexibility for the user and allowing them to decide how to configure things. Changing the connection info at runtime is a nice benefit (maybe an edge case) but would allow specifying the connection details at app boot time instead of compile time.

Is this a naming convention in neo4j or is there some technical benefit for doing this? Though I agree it’s best to stick to conventions where possible.

For handwritten queries using seraph maybe having a macro that supports handling field names might work out. Ecto has a macro for dealing with dynamic fields (field/2) perhaps something similar to that or maybe something like fragments which allows a field value to be passed in. Honestly, I haven’t given it much thought at this point but would like to dive into the code and check it out more.

domvas

domvas OP

For labels and types, it’s Neo4j’s recommendation and can be seen as a convention.
For properties, it’s based on what I’ve seen during my trainings and many talks / tutorials. So a majority of users has adopted this syntax but it’s not really a convention, then letting the end-user decide could be nice.
Having a field/2-like macro can be tricky to implement but not impossible then it will be implemented. It is in fact one the many features that still missing (like fragments…)

pmangalakader

pmangalakader

Trying it for some fun project, easy to use it like ecto seems excellent. Would love to see transaction support in the future releases.

alaadahmed

alaadahmed

wow really nice work you have done @domvas, really appreciate your work, I am working on some big project that I intend to use neo4j for it. I am reading your guides and I am fascinated. I hope you still maintain this library and keep it up to date.

— All posts loaded —

Where Next? Top

Trending in Announcing Top

woylie
Flop is an Elixir library that applies filtering, ordering and pagination parameters to your Ecto queries. offset-based pagination with...
New
MRdotB
I needed to reuse React components from my Chrome extension in my Phoenix/LiveView backend. I noticed that for Svelte/Vue, there are live...
New
woylie
I released Doggo, a collection of unstyled Phoenix components. https://github.com/woylie/doggo Features Unstyled Phoenix components....
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
anuaralfetahe
Hello Published a new library - ProcessHub! ProcessHub is a library designed to manage process distribution within the Elixir cluster. ...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New

Other Trending Topics Top

mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New
sergio
It’s not that it’s vocabulary is too advanced. It’s something worse. I get lost trying to follow even a paragraph written by Claude. It’...
New
AstonJ
This showed up on my feed.. anyone heard of it? Just hype? Ox Alpha is a reasoning model designed for coding, sustained ag...
New
bartblast
Hey folks, I just published a post about Hologram’s funding and where the project goes next - the short version: Curiosum as Main Spons...
New
sorenone
Today we’re releasing Oban for Python. Not an Oban client in Python. Not a pythonx wrapper embedded in Elixir. Nope, it’s a fully operati...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews