Major changes in v0.9

(Pawan Rawal) #22

Yes, we will definitely have a post about it. Probably on discuss.

(Wolf Dan) #23

As I mention ^^’ the library is not ready for production yet which is sadly :confused:

@pawan It has definitely been decided to use just Grcp to communicate with Dgraph? Just to be sure and begin to build something to Elixir ^^

(Sunny G) #24

@WolfDan I think this library is worth looking into and bringing up to date with 0.9:

(Manish R Jain) #25

We’re planning to add HTTP endpoints to allow queries and separately, mutations. They won’t be transactional in nature, but would at least give most of the current functionality.

(Wolf Dan) #26

Sure @sunny-g I already created a PR to improve a little bit the library ^^ still waiting to merge :smiley:

That’s a great notice @mrjn ! This allow us to have more time to get done a more native solution with Grpc in Elixir :smiley:

(Manish R Jain) #27

@pawan is building the HTTP interface and looks like it would also allow transactions – He can expand more when he’s close to done on this thread.

(Jeff Hull) #28

Man you guys move fast. I admire what you’re able to do with a small team. Would be cool to hear your advice on building a small, high performance dev team if you guys feel you have taken any novel approaches worth calling out specifically.

Anyway, loving this constant stream of great features!

(Manish R Jain) #29

Thanks for the kind remarks! I’ll explain with an analogy, the centerpiece of our hiring strategy.

There’s this particular strategy in Dominion, the popular board game. While the goal of the game is to have the highest valued deck, you trash out all the copper cards, as early as possible. Then, you’re able to draw more silvers and golds in every turn; which then lets you buy more powerful cards each turn and win the game swiftly.

The way I think about developers is the same. In an early stage startup, when you want to move fast and be thrifty, you should get rid of any engineer who is not able to get things done. This then leaves you with a few engineers who are solid performers – which sets the stage for speed being a part of the culture of the team. The team members are then able to feed off each other and keep building the momentum.

Conversely, having a few slow engineers would cause an otherwise fast engineer to also take it slow; the weak-link in the chain. Additionally, there is a significant communication overhead per engineer, which also takes away from the speed of execution; so its very important to select then only keep strong performers.

Also, I believe strongly in the power of individuals. While teams are very important for projects, single developers have been the driving force behind the most important technical projects. So, giving big chunks of work to one dev is something we do naturally.

(Pawan Rawal) #30

I have updated the original post. We will have full transaction support using http. We will put up the docs mentioning in detail how to use the new API to do transactions.

Quoting from the original post.

(Jeff Hull) #31

Thanks @mrjn, this makes sense and is helpful.

Couple more questions:

  • Do you guys keep an official “coding standards / guidelines” doc, or is it informal?
  • How aggressive are you about adopting new technology in the codebase where there is a new, demonstrably better solution, versus keeping the existing solution so as to not destabilize the existing code?

(Sunny G) #32

@mrjn are subscriptions still a part of the product roadmap? I could have sworn at some point in the recent past that subscriptions were slated for a v0.8 (or v0.8 maybe) release.

(Manish R Jain) #33

Before v1.0 is released, we’d go with the best solution to the problem, which sometimes means significantly modifying our APIs. You see that happening right now with transactions, etc.

After v1.0, we’ll maintain the current branch, and if we have a much better solution, we’ll just cut a new major release to avoid breaking changes.

We used to have a doc, it’s still online somewhere. We have strict code reviews before anything gets submitted, and we’re constantly trying to refactor our code and simplify our solutions. Given we’re all sitting next to each other, we don’t feel the need to keep an up-to-date guidelines doc.

No one showed support for it, so we just delayed it. Once we cut v0.9, we could build it, so it would be there in v0.9.x. I’ll tag it as such.

(Sunny G) #34

No one showed support for it, so we just delayed it. Once we cut v0.9, we could build it, so it would be there in v0.9.x. I’ll tag it as such.

@mrjn Please do, you have a +1 from me! Real-time GraphQL queries on a distributed graph database is too enticing to ignore :slight_smile:

(Calum Moore) #35

Yes agree, subscriptions would be an awesome feature! It was the main selling point for Rethink DB and it got a lot of traction because of it (notwithstanding the ultimate outcome of Rethink…).

(Manish R Jain) #36

Embedded Dgraph goes away

We haven’t seen much usage of this feature. And it adds unnecessary maintenance overhead to the code. If there are clear reasons for its benefits, let us know (

(Calum Moore) #37

I’m not using it.

In the upcoming release, will unique indexes be included as part of transactions, or will we still need to manage that outside of Dgraph?

Also, I’m looking to go live with a new app shortly, but it seems like 0.9 will be a fairly major change, so might be worth waiting. Any updated view on when it might be available (no worries if not)?

Unique Indexes on predicates
(Lazhar Ichir) #38

Had to be away for a few days as moving to a new country but guys, I’ve never been so happy to see a feature back. These HTTP endpoints mean the world to me, ha! Will look at how to implement upserting with these as soon as I can get back on my code.

Thank you again, you guys really rock.

(Peter Stace) #39

@calummoore, we expect to release v0.9 today, so not long to wait now :smiley:

(Manish R Jain) #40

I’m not sure what you mean by unique indexes. So, my guess is that you’re asking about enforcing single edge nodes? That’s not built yet.

With v0.9, we really want to push v1.0 out the door, so depending on how well it goes, we might release v1.0 in a month or so, and push all feature requests to after v1.0 release.

I’m really glad that you liked it. You can thank @pawan who found a good way to integrate transaction metadata into the HTTP endpoints :slight_smile:.

(Calum Moore) #41

Struggling to get a mutation to work in 0.9 using HTTP, I have a feeling that everything is going into a transaction (which I may have inadvertently created when I first started a server), but I’ve restarted the server and dropped the DB so I would be surprised if the transaction is still open.

  1. Start with a clean build (not attaching a data volume in case that leaves something behind)
    docker rm diggy

    docker run -it -p 8080:8080 -p 9080:9080 --name diggy dgraph/dgraph dgraph zero --port_offset -2000

    docker exec -it diggy dgraph server --memory_mb 2048 --zero localhost:5080

    localhost:8080/alter -> {"drop_all": true}

  2. Add a schema
    localhost:8080/alter -> name: string @index(term) .

  3. Add Bob and Alice

	set {
		<_:bob> <name> "Bob" .
		<_:bob> <balance> "70" .

		<_:alice> <name> "Alice" .
		<_:alice> <balance> "100" .
    "data": {
        "code": "Success",
        "message": "Done",
        "uids": {
            "alice": "0x2",
            "bob": "0x1"
    "extensions": {
        "txn": {
            "start_ts": 2,
            "keys": [
            "lin_read": {
                "ids": {
                    "1": 11
  1. Query for bob and alice (seems like the mutation hasn’t been committed…)?
  balances(func: allofterms(name@en, "Alice")) {
    "data": {
        "balances": []
    "extensions": {
        "server_latency": {
            "parsing_ns": 21874,
            "processing_ns": 193677,
            "encoding_ns": 1124903
        "txn": {
            "start_ts": 3,
            "lin_read": {
                "ids": {
                    "1": 13

I’ve not sent any headers on any of this.