AshNeo4j Datalayer
Ash Neo4j is a Datalayer for Neo4j
https://github.com/diffo-dev/ash_neo4j/
'Why have an Ash Neo4j DataLayer?
I've been using developing systems for about 30 years, often working with relational databases. I've been developing with graph databases for the last four years. I've found graph aligns naturally with the way I think about things and how they are related. Graphistas see graphs everywhere, because they are everywhere. Graph is similar to Elixir, in that once you start you don't want to go back. In fact life is too short, I won't go back...
Similarly I've found Ash to be an exceptional framework for declarative application development. It has a learning curve, however the Ash way is to use and build abstractions for exceptional maintainability.
The Ash Framework contains some basic datalayers and the ecosystem already offers a choice of datalayer extensions, including the popular and feature rich AshPostgres above the open source Postgres.
I hitched my wagon to Ash Framework aware of the lack of graph datalayers, knowing that they could be built using an Ash Extension. Indeed Ash does a good job of abstracting SQL databases away and making refactorings easier, so arguably there is less demand for such a thing. However as you refactor your resources you still need to migrate database schemas - so the complexity doesn't go away, it is just better hidden.
Neo4j is defacto in data science and well entrenched in security, fraud, logistics, network management and recommendation applications. Increasingly our applications need to work with both facts and knowledge and these are best represented using graphs.
So here we both are with Ash and graph. Enjoy the combination.'
There is a livebook of course you'll need Neo4j too.
Let me know how you find it/what issues you encounter.
GitHub
GitHub - diffo-dev/ash_neo4j: Ash Neo4j datalayer
Ash Neo4j datalayer. Contribute to diffo-dev/ash_neo4j development by creating an account on GitHub.
7 Replies
Incredible work! Can’t wait to see how this evolves. I’m working with a client who really loves his graph databases but is disillusioned with arangodb which is what he’s using at the moment so I’ll be keeping my eyes on it.
Yes there is a quite a bit more to do: aggregations, calculations, fragments, calculation queries, composite queries, points and other geo classes and vector embeddings, to name a few. I'll do some of these as I need them, otherwise open to PR's.
One thing I really do want to do soon is relationship properties. I've got a discussion going here https://github.com/diffo-dev/ash_neo4j/discussions/4 Currently the 'connector' resource pattern is supported but you'll get an intermediate node with properties, but I'd like to do this the 'neo4j way' with a direct relationship enriched with properties. This will mean you can' t actually have a connector that is disconnected, since a relationship can't exist unless between a source and destination node.
GitHub
Relationship properties · diffo-dev ash_neo4j · Discussion #4
In graph database both Nodes and Relationships are first order concepts. Relationships relate exactly two nodes, and may have properties, otherwise like node properties. However there is an impedan...
I've just raised an issue https://github.com/sagastume/boltx/issues/123 and PR on the underlying Boltx to improve the version negotiation, which will avoid having to set the BOLT_VERSIONS environment variable, which is a hassle in livebook. Hopefully it gets reviewed and merged.
GitHub
Enhancement, improve bolt version negotiation to support ranges · ...
Bolt version negotiation supports ranges. Boltx should support this too, although obviously older databases won't support this negotiation option. Given that only four versions can be offered b...
What does a graph database do better than a relational database?
Great q for AI. Dealing with complex queries on highly interconnected data. In my trade OSPF queries (constraint based routing - the basis of the internet’s BGP) is easy with graph but complex/non-performant with relational.
But essentially in graph you model things and relationships as the exist, rather than some weird way because you have to. This ultimately improves your data, extensibility and provides you with insights and opportunities.
Explore graph and find out for yourself.
Sometimes it means things could be done a bit differently/more naturally For example with service/resource events I like to chain these events (Service)-[FIRED]->(Event)-[AFTER]->(Event), such that we have chains of events, where we insert a new FIRED event at the head of a chain. When reading the Service normally bring in the adjacent nodes so have last event, if I want to show last n can just traverse from the serivce n events. When deleting history archiving (:-) I can just detach/delete from the last one I care about.
Totally great project! I am working on a datalayer for knowledge-graph myself, so glad other graph databases users are out there.