mrjn
October 19, 2017, 10:07pm
4
We’re adding support for transactions.
opened 05:15PM - 12 Sep 17 UTC
closed 07:51AM - 14 Nov 17 UTC
kind/enhancement
Hello developers,
Thanks so much for bringing this graph database into the mark… et as an open source and self-contained Go project. It's the first time in the last several years that I'm again excited about a new database development. Considering what I've seen so far, this may soon be a great candidate for small and large projects, even in cases not originally associated with graph databases.
Given my experience with databases in general and as the author of the [MongoDB driver for Go](http://labix.org/mgo), the one thing that makes me concerned to recommend its use in [Canonical](https://canonical.com) or more widely is the lack of transactions.
Over the years this has been a constant nuisance with MongoDB, to the point where I even wrote [client side transaction support](https://blog.labix.org/2012/08/22/multi-doc-transactions-for-mongodb) that abuses atomic implementation details to achieve general multi-document transactions. My hope is that this would be short-lived, but here we are, 5 years later.
Upstream is discussing the fix since the project started pretty much ([#2804](https://jira.mongodb.org/browse/SERVER-2804), [#11500](https://jira.mongodb.org/browse/SERVER-11500), [#11508](https://jira.mongodb.org/browse/SERVER-11508), etc), and there are hints that yet another small step may be coming soon ( [#28903](https://jira.mongodb.org/browse/SERVER-28903), [#30325](https://jira.mongodb.org/browse/SERVER-30325), etc), but it's clear that being an afterthought affected the design and the cost of the solution, not to mention the use cases.
So, coming back to Dgraph, if the idea is indeed to position it as a general alternative for existing databases as I've watched in one of your videos, please don't make the same mistake of postponing transactions for too long, or voicing them as relevant mainly for financial transactions. The sort of consistency at stake is relevant for pretty much any application at all that uses data, even more when even basic details about a record are recorded as multiple individual terms. This would make the situation even worse than with MongoDB.
On the bright side, given the current implementation of Dgraph and the existing form of mutation operations, it feels like you are in a much better position to solve the problem already, and with a good solution you also get the attention of a currently suffering user base that will be interested in hearing your story.
I can't promise that since we're not a current user of Dgraph (and might not be while this is an issue), but depending on the case I can even try to advocate internally for some funding towards the solution for this problem.
Thanks for your consideration, and in either case thanks again for your work on this promising database.
Once they’re released in v0.9, you can achieve what you need easily without upsert. For that matter, there won’t be any upserts in v0.9; because txns would provide a super set of upsert functionality.
1 Like