Dgraph v1.1.0-rc3 release candidate

Announce
1

Hey folks,

Please try out our latest release candidate v1.1.0-rc3. If you find any issues, please let us know so we can address them before the final v1.1.0.

The full list of changes for v1.1.0 is available in the CHANGELOG. There are LOTS of significant changes and features in this version. They’re all covered in the CHANGELOG, so please take a look and let us know what you think! Dgraph v1.1 is NOT backwards compatible with Dgraph v1.0.

Notable changes:

Link to binaries: Linux, Darwin, Windows.

Also published on Docker tagged as v1.1.0-rc3.

Note: This is not the official release. You won’t be able to get these binaries using the get.dgraph.io quick install script.

$ dgraph version

Dgraph version   : v1.1.0-rc3
Dgraph SHA-256   : 68de14c27a63d57afe9264cea5da88f8da165032f86fc0ccc5a61dbaf363b9ca
Commit SHA-1     : 7cbdaece
Commit timestamp : 2019-08-27 19:36:17 -0700
Branch           : HEAD
Go version       : go1.12.7

Cheers,

The Dgraph Team

3 Likes
2

Should be CHANGELOG

1 Like
3

Hi, sorry for bringing this again, but still I can’t get around the new Type system.

Using dgraph v1.1.0-rc3

The schema is set as:

		type Person {
			name:     string
			age:      int
			married:  bool
		}
		name: string .
		age: int .
		married: bool .

and the struct for it:

	type Person struct {
		Uid      string   `json:"uid,omitempty"`
		Name     string   `json:"name,omitempty"`
		Age      int      `json:"age,omitempty"`
		Married  bool     `json:"married,omitempty"`
	}

After inserting a record, querying dgraph like:

	const q = `{
		expander(func: has(name)) {
			uid
			expand(_all_) {
				uid
				expand(_all_)
			}
		}
	}`

	resp, err := dg.NewTxn().Query(ctx, q)
	if err != nil {
		log.Fatal(err)
	}

	fmt.Println(string(resp.Json))

It only yields: {"expander":[{"uid":"0x3fb2f"}]}

What I’m doing wrong?

4

You need something like

type Person struct {
     DgraphType  string `json:"dgraph.type,omitempty"`
}

and add the “Person” value.

Like this

5

Oh I have missed that :blush:

It expands it properly now, however only the forward edges, can’t get it to expand when there is a reverse edge:

with schema:

		age: int .
		married: bool .
		friend: [uid] @reverse .
        type Person {
          name: string
          age: int
          married: bool
          friend: [uid]
        }

        type Friend {
          name: string
          age: int
          married: bool
        }

Unless friends is of type Person dgraph expands only the queried uid without reverse:

{
  node(func: uid(0xb)) {
    uid
    expand(_all_) {
      uid
      expand(_all_)
    }
  }
}

returns

{
  "data": {
    "node": [
      {
        "uid": "0xb",
        "age": 24,
        "name": "Bob"
      }
    ]
  },
...
}

Same query works fine if uid have forward edges:

{
  "data": {
    "node": [
      {
        "uid": "0xa",
        "name": "Alice",
        "age": 26,
        "married": true,
        "friend": [
          {
            "uid": "0xb",
            "name": "Bob",
            "age": 24
          },
          {
            "uid": "0xc",
            "name": "Charlie",
            "age": 29
          }
        ]
      }
    ]
  },
...
}

I’ve looked at the tests again but couldn’t see any different definition for the reverse edges apart from @reverse in the scheme.

6

change this type to:

friend: [Friend]
7

I see, makes sense, however although in ratel schema explorer it does now show friend records having ~friend edges, expand(all) still doesn’t expand the reverse edges when one is requested.

p.s. that’s the result of schema{} query if its of any help

{
	"schema": [{
		"predicate": "age",
		"type": "int"
	}, {
		"predicate": "dgraph.type",
		"type": "string",
		"index": true,
		"tokenizer": ["exact"],
		"list": true
	}, {
		"predicate": "friend",
		"type": "uid",
		"reverse": true,
		"list": true
	}, {
		"predicate": "married",
		"type": "bool"
	}, {
		"predicate": "name",
		"type": "string"
	}],
	"types": [{
		"fields": [{
			"name": "name",
			"type": "string"
		}, {
			"name": "age",
			"type": "int"
		}, {
			"name": "married",
			"type": "bool"
		}],
		"name": "Friend"
	}, {
		"fields": [{
			"name": "name",
			"type": "string"
		}, {
			"name": "age",
			"type": "int"
		}, {
			"name": "married",
			"type": "bool"
		}, {
			"name": "friend",
			"type": "[Friend]"
		}],
		"name": "Person"
	}]
}
8

Use for that case.

expand(_reverse_)
9

Nope, no change. I’ll stick for now with v1.0.16 seems.

Thank you for your time!

10

Well, not sure what you’re doing. I’ve just tested it and is working great.

The reverse edge is showing up with expan(_all_)

{
  node(func: uid(0x1)) {
    uid
    expand(_all_) {
      uid
      expand(_all_)
    }
  }
}

{
  "data": {
    "node": [
      {
        "uid": "0x1",
        "name": "Charlie",
        "age": 29,
        "~friend": [
          {
            "uid": "0x2",
            "name": "Alice",
            "age": 26,
            "married": true
          }
        ]
      }
    ]
  },
  "extensions": {
    "server_latency": {
      "processing_ns": 526997100
    },
    "txn": {
      "start_ts": 22
    }
  }
}

{
  "data": {
    "schema": [
      {
        "predicate": "age",
        "type": "int"
      },
      {
        "predicate": "dgraph.type",
        "type": "string",
        "index": true,
        "tokenizer": [
          "exact"
        ],
        "list": true
      },
      {
        "predicate": "friend",
        "type": "uid",
        "reverse": true,
        "list": true
      },
      {
        "predicate": "married",
        "type": "bool"
      },
      {
        "predicate": "name",
        "type": "string"
      }
    ],
    "types": [
      {
        "fields": [
          {
            "name": "name",
            "type": "string"
          },
          {
            "name": "age",
            "type": "int"
          },
          {
            "name": "married",
            "type": "bool"
          }
        ],
        "name": "Friend"
      },
      {
        "fields": [
          {
            "name": "name",
            "type": "string"
          },
          {
            "name": "age",
            "type": "int"
          },
          {
            "name": "married",
            "type": "bool"
          },
          {
            "name": "friend",
            "type": "[Friend]"
          }
        ],
        "name": "Person"
      }
    ]
  },
  "extensions": {
    "server_latency": {
      "assign_timestamp_ns": 995300
    },
    "txn": {
      "start_ts": 26
    }
  }
}
11

Clearly I’m missing something although the schema query looks the same.

This is the test Go program:

Was testing using the official dgraph/dgraph:v1.1.0-rc3 docker image.

12

Here, i’ve fixed your code.
The issue was the struct and the JSON structure.

{"expForward":[{"uid":"0xa","name":"Alice","age":26,"married":true,"friend":[{"uid":"0xb","name":"Bob","age":24},{"uid":"0xc","name":"Charlie","age":29}]}]}

{"expReverse":[{"uid":"0xb","~friend":[{"uid":"0xa","name":"Alice","age":26,"married":true}],"name":"Bob","age":24}]}

BTW, you don’t need the Friend struct.

13

Apologies for that, tried to stick to dgraph test examples which only added to the confusion

I should have made it completely different from the Person to demonstrate the issue.

The whole point is having edges which aren’t the same node just linking to itself.

Here is parts from the real structs however they don’t change anything, the code behaves exactly the same no matter what bad name I’d chose :slight_smile:

type Article struct {
	Uid    string `json:"uid,omitempty"`
	Title  string `json:"title,omitempty"`
	Points int    `json:"points,omitempty"`

	// fields redacted for brevity

	DgraphType string `json:"dgraph.type,omitempty"`
}

type Author struct {
	Uid         string `json:"uid,omitempty"`
	Name        string `json:"name,omitempty"`
	Age         int    `json:"age,omitempty"`
	Nationality string `json:"nationality,omitempty"`

	// fields redacted for brevity

	Articles   []Article `json:"articles,omitempty"`
	DgraphType string    `json:"dgraph.type,omitempty"`
}

Author (Person) and []Articles([]Friend) so the struct is right, reverse works only if the edge is of the same type which then expands only the node but reverse fields are lost and vice versa.

	p := Author{
		Uid:        "_:alice",
		Name:       "Alice",
		Age:        26,
		DgraphType: "Author",
		Articles: []Article{{
			Uid:        "_:article1",
			Title:      "West",
			Points:     3,
			DgraphType: "Author",
		}, {
			Uid:        "_:article2",
			Title:      "East",
			Points:     7,
			DgraphType: "Author",
		}},
	}

expands as:

{"expForward":[{"uid":"0x2c","articles":[{"uid":"0x2b"},{"uid":"0x2d"}],"name":"Alice","age":26}]}
{"expReverse":[{"uid":"0x2d","~articles":[{"uid":"0x2c","name":"Alice","age":26}]}]}

While:

	p := Author{
		Uid:        "_:alice",
		Name:       "Alice",
		Age:        26,
		DgraphType: "Author",
		Articles: []Article{{
			Uid:        "_:article1",
			Title:      "West",
			Points:     3,
			DgraphType: "Article",
		}, {
			Uid:        "_:article2",
			Title:      "East",
			Points:     7,
			DgraphType: "Article",
		}},
	}

expands as:

{"expForward":[{"uid":"0x37","articles":[{"uid":"0x38","title":"West","points":3},{"uid":"0x39","title":"East","points":7}],"name":"Alice","age":26}]}
{"expReverse":[{"uid":"0x38","title":"West","points":3}]}
14

Okay, I’ve copy your examples and tried to reproduce (And it’s working). The only thing I think I’ve made different was the Type. I’ve added a articles: [Author] to Article type. I think Dgo is more restrict about types.

last test results:

{"expForward":[{"uid":"0x48","name":"Alice","age":26,"articles":[{"uid":"0x47","title":"West","points":3},{"uid":"0x49","title":"East","points":7}]}]}

{"expReverse":[{"uid":"0x47","points":3,"~articles":[{"uid":"0x48","name":"Alice","age":26}],"title":"West"}]}
15

BTW, an important point to note. It is not recommended to use expand(*) func all the time if you need predictable results. It is recommended that you use full queries, with all required predicates. And when using Reverse, use Alieases. When using Aliease you must add it in Type Schema beforehand. Thus making it a predictable and controlled result.
eg.

// Reverse query
	var qr = fmt.Sprintf(`{
		expReverse(func: uid(%s)) {
			uid
			points
			title
			author : ~articles {
				name
				age
			}
		}
	}`, bob)

{"expForward":[{"uid":"0x53","name":"Alice","age":26,"articles":[{"uid":"0x54","title":"West","points":3},{"uid":"0x55","title":"East","points":7}]}]}

{"expReverse":[{"uid":"0x54","points":3,"title":"West","author":[{"name":"Alice","age":26}]}]}


		age: int .
		articles: [uid] @reverse .
		name: string .
		nationality: string .
		title: string .
		
	    type Author {
	      name: string
	      age: int
	      nationality: string
	      articles: [Article]
	    }
	    type Article {
		  title: string
		  points: int
		  author: [Author]
		}
16

Hi Michel,

That made all the difference! :slight_smile: I feel like it should be a bit clearer in the documentation for the type system. Or at least on dgo client.

I do agree on that, besides using expand(*) in production query is makes it unclear what I will get back to my struct in Go if used that way, with that said expand(*) queries are quite helpful when bootstrapping queries or just exploring the data quickly in ratel and it wasn’t working, now I can try and use 1.1.0-rc* releases in staging/production for more realistic tests.

Again, thank you very much indeed for taking time to test and explain this!

1 Like