Memgraph Support?

[yourbuddyconner]

I see that memgraph support is on the README -- wondering if any of the contributors to this package know off the top of their head the things that would need to change in this library to enable support for Memgraph.

At the very least, version parsing here needs to be updated (looks like memgraph returns v5 instead of a semver).

I really like and appreciate the use of Pydantic at the core of this library, and would be down to contribute this feature so I dont have to use gqlalchemy.

[groc-prog]

I know there are some differences in indexing and constraints for sure, but i haven't really looked too much into memgraph. I have found this link from the docs listing some of them.

I haven't really got that much time right now since i am busy with some things in my life, but you are welcome to lay out a basic plan for what would have to be changed and how to best integrate this into the existing code base. Memgraph integration was more of a afterthough since the project for which i originally created this library for used Neo4j from the start but we later wanted to migrate to Memgraph for performance reasons.

If you have any ideas keep me posted.

[groc-prog]

I found some time to look over the codebase and pick out the parts which would probably need some refactoring or at least some small changes to support the syntax differences between the two DBs. Here is a list of things i found (though i might have missed some):

• DB version parsing (as mentioned previously)
  • The parsing is already pretty basic and only exists because i could not be bothered to test this library against older versions of Neo4j since i did not need it
• Indexing on Labels/Types/Properties/...
  • This could potentially be a bit more work since not all index types are supported for each DB
• Uniqueness constraints
  • should be easy to implement since it is only a slight syntax change
• Subqueries used in combination with EXISTS (can potentially be solved by using the exists() pattern function)
  • Could again be a bit more work, but it shouldn't be too complicated since pyneo4j only supports patterns that can not be nested
• Conditional expressions using CASE
  • should be a easy to implement since the syntax is only slightly different but basically provides the same functionality
• Usage of elementId is not supported in Memgraph
  • This is a bit more work since we somehow need to "disable" the elementId operator when Memgraph is used as a DB instead

As for how to best integrate it into the existing code base, i still don't have not decided on the best approach. As far as changes go, these affect the client class (indexing/constraints/version parsing), the query builder (basically all differences in query structure/unsupported functions) and the operator builder (for the elementId operator). Another concern would be typing based on the used DB, since the current typings would be wrong for Memgraph queries.

As for migrations, if the rest works they should work as well since they are basically only a few queries which actually interact with the database.

The best approach would probably be to integrate basic support for indexes/constraints/manual queries and tackle things like query building and operators as the underlying logic comes along.

I am going to keep you posted if i find the time to actually get started on this.