graphtage VS gqlalchemy

I'm not familiar with Pijul, and haven't finished watching this presentation, but IME the problems with modern version control tools is that they still rely on comparing lines of plain text, something we've been doing for decades. Merge conflicts are an issue because our tools are agnostic about the actual content they're tracking.

Instead, the tools should be smarter and work on the level of functions, classes, packages, sentences, paragraphs, or whatever primitive makes sense for the project and file that is being changed. In the case of code bases, they need to be aware of the language and the AST of the program. For binary files, they need to be aware of the file format and its binary structure. This would allow them to show actually meaningful diffs, and minimize the chances of conflicts, and of producing a corrupt file after an automatic merge.

There has been some research in this area, and there are a few semantic diffing tools[1,2,3], but I'm not aware of this being widely used in any VCS.

Nowadays, with all the machine learning advances, the ideal VCS should also use ML to understand the change at a deeper level, and maybe even suggest improvements. If AI can write code for me, it could surely understand what I'm trying to do, and help me so that version control is entirely hands-free, instead of having to fight with it, and be constantly aware of it, as I have to do now.

I just finished watching the presentation, and Pijul seems like an iterative improvement over Git. Nothing jumped out at me like a killer feature that would make me want to give it a try. It might be because the author focuses too much on technical details, instead of taking a step back and rethinking what a modern VCS tool should look like today.

[1]: https://semanticdiff.com/

[2]: https://github.com/trailofbits/graphtage

[3]: https://github.com/GumTreeDiff/gumtree

Vielleicht mal https://github.com/trailofbits/graphtage abchecken

Graphtage: A semantic diff utility for JSON, HTML, YAML, CSV, etc\ (42 comments)

As already mentioned, link prediction refers to the task of predicting missing links or links that are likely to occur in the future. In this tutorial, we will make use the of MAGE spell called node2vec. Also, we will use Memgraph to store data, and gqlalchemy to connect from a Python application. The dataset will be similar to the one used in this paper: Graph Embedding Techniques, Applications, and Performance: A Survey.

For any other service provider, it is possible to implement your custom importer class, here's how. Don't forget that GQLAlchemy is an open source project, so you can submit your extended functionality on our GitHub repository.

If you think there is something crucial that is missing or are even willing the try out your expertise in Python and graphs, check out our GitHub repository and feel free to contribute.

gqlalchemy – a Python driver and object graph mapper (OGM)

There is a broad number of drivers in many different programming languages available for both solutions. While Memgraph only maintains a few in-house drivers that it develops and supports (C, C++, Python, Rust), most Neo4j drivers can also be used with Memgraph. This is due to the fact that both solutions use the Bolt protocol, labeled property graph model and Cypher query language.

Memgraph natively has several methods of data import - import from files, MySQL or PostgreSQL, and data streams. Memgraph is also highly extendable, and with the help of its Python client, GQLAlchemy, you can import data from almost anywhere.

Source code for GQLAlchemy is available at GitHub repo.

I think building your graph database/structure can be quite an engineering and time-consuming challenge, as you mentioned, which I would personally avoid. I believe there are some solutions out there that may help you. There is one open source solution for the requirements and concerns you are mentioning. It checks out most of the things you need, functionality, efficiency, and custom low-level optimizations and it is not bulky as the Neo4j Java backend. In essence, we have built Memgraph an in-memory graph database written in C++. The distinctive key feature of DB is that all the data is stored in RAM for fast queries. There is some cool stuff with ML for graphs. Take a look at this blog post about node embedding and recommendation engines, it is native integration with Python and uses PyTorch. There is also the MAGE library for graph algorithms and ML, it is also open-sourced, which is great news for customization and expansions. I share your thoughts on OpenCypher, as being an issue. Memgraph has an object graph mapper (similar to ORM), called GQLAlchemy, and is in Python. There is also a learning curve, but not a different new skill as Cypher. The good thing is allowed various features for graphs manipulation via Python. There are also some other solutions such TigerGraph, Nebula, etc. But I am not very familiar with them. Feel free to explore. I hope this helps! 😁

Using gqlalchemy we are trying to connect to Memgraph, just like we have done before in our backend.

As expected, Flask is there, so it will be installed in our container. Next, we have pymgclient, Memgraph database adapter for Python language on top of which gqlalchemy is built. We will connect to the database with gqlalchemy and it will assist us in writing and running queries on Memgraph.