Question

I’m currently building a web service using python / flask and would like to build my data layer on top of neo4j, since my core data structure is inherently a graph.
I’m a bit confused by the different technologies offered by neo4j for that case. Especially :

1. i originally planned on using the REST Api through py2neo , but the lack of transaction is a bit of a problem.

2. The “embedded database” neo4j doesn’t seem to suit my case very well. I guess it’s useful when you’re working with batch and one-time analytics, and don’t need to store the database on a different server from the web server.

3. I’ve stumbled upon the neo4django project, but i’m not sure this one offers transaction support (since there are no native client to neo4j for python), and if it would be a problem to use it outside django itself. In fact, after having looked at the project’s documentation, i feel like it has exactly the same limitations, aka no transaction (but then, how can you build a real-world service when you can corrupt your model upon a single connection timeout ?). I don’t even understand what is the use for that project.

Could anyone could recommend anything ? I feel completely stuck.

Thanks

Answer 1

None of the REST API clients will be able to explicitly support (proper) transactions since that functionality is not available through the Neo4j REST API interface. There are a few alternatives such as Cypher queries and batched execution which all operate within a single atomic transaction on the server side; however, my general approach for client applications is to try to build code which can gracefully handle partially complete data, removing the need for explicit transaction control.

Often, this approach will make heavy use of unique indexing and this is one reason that I have provided a large number of “get_or_create” type methods within py2neo. Cypher itself is incredibly powerful and also provides uniqueness capabilities, in particular through the CREATE UNIQUE clause. Using these, you can make your writes idempotent and you can err on the side of “doing it more than once” safe in the knowledge that you won’t end up with duplicate data.

Agreed, this approach doesn’t give you transactions per se but in most cases it can give you an equivalent end result. It’s certainly worth challenging yourself as to where in your application transactions are truly necessary.

Hope this helps

Nigel