-
-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Elixir storage backend for libgit2. #2
Comments
We got our first experimental PostgreSQL backend. Switching backends is easy as setting Loading the PostgreSQL backend is provided by {:ok, repo} = GitRekt.Git.repository_load({:postgres, repo_id, "postgresql://localhost/my_db"}) Git objects and references are stored in Postgres database configured for I could not notice any great performance improvements so far. A direction I would like to go in future iterations is storing Git objects in separated SQL tables depending on their type (commit, tag, tree, blob, etc.). This way we might be able to optimise slow commands such as counting commits or querying history for a specific pathspec. |
Closing this because implementing a loopback (Elixir -> NIF -> Elixir) seems not feasible currently. A while ago, I've stumbled across this presentation: Future Extensions to the Native Interface. |
When calling GitRekt.GitAgent from other nodes, NIF resources might be garbage collected between two calls: {:ok, head} = GitRekt.GitAgent.head(agent) {:ok, commit} = GitRekt.GitAgent.peel(agent, head) #1 {:ok, message} = GitRekt.GitAgent.commit_message(agent, message) #2 In the above example, between #1 and #2 the agent process might garbage collect the commit. This could lead lead to a bad argument error in #2. In order to counter this, GitRekt.GiAgent stores a set of borrowed NIF resources. This way the resources are reference counted and available between consecutive calls. Note that the references are dropped once a :DOWN message is received from a given client process.
The libgit2 libraries provide a mechanism to plugin our own backend for storing Git data.
A very interesting way to investigate would be to have the libgit2 backend communicate with our application (by exchanging messages) by implementing an Erlang port driver.
I'm not sure at all that this is in any way performant. We will have to do a lot of benchmarks here!
The text was updated successfully, but these errors were encountered: