There was a user today who wants to extract a graph with attributes from neo4j (https://neo4j.com/) which is a graph database and manipulate it in igraph. That case was about R and there is a thing called neo4r (https://github.com/neo4j-rstats/neo4r), but it made me think of whether we should be doing anything about that at the C level or at the Python level. That also plugs into Vincent’s argument yesterday that people LOVE interoperability.
Looking at neo4r, the impression is that it’s nice but pretty easy to do. However, connecting to databases involves some degree of network issues (not necessarily involving the internet, but still) which would be fairly new ground in our codebase. On the other hand, I think neo4j might be popular enough that adding support would help a bunch of people.
Any opinions about adding this converter in C/Python? I’d be happy to take a stab at it if we all agree it doesn’t become a horrible burden to maintain.
Sorry, I forgot to visit the Discourse group recently and I only noticed this new topic today when I got the weekly summary email.
Anyway, I wouldn’t try to tackle this in the C layer – the related network communication seems too involved to do in C directly; it’s certainly possible but it would drive away the focus from more important things in the C layer. Also, I think that people who work with Neo4J most likely don’t do that on the abstraction level that C provides, so there is probably more benefit in trying to implement the interoperability in the high-level interfaces.
As for Python, it looks like there is a basic way to do it with py2neo (see this SO page). The relevant answer on SO is pretty old and I don’t know whether it still works or whether there’s a more mature solution now, but it’s definitely worth looking into. I don’t know how much of a maintenance burden it will be in advance - we need to look into standard Neo4J interface modules in Python and see what they provide; if they provide an easy way to convert Neo4J data into basic Python lists and dicts, then maybe we only need to improve the TupleList and DictList constructors a bit and then glue the two ends together.