Simplify type definitions.

[martinmr]

Type definitons are now simpler as the type of the fields is not
required anymore. The new format is:

type Person {
  name
  address
  ssn
}

---

This change is 

[pullrequest]

✅ A review job has been created and sent to the PullRequest network.

---

@martinmr you can click here to see the review status or cancel the code review job.

[pawanrawal]

Mostly looks good. Please also consider cases of export/import of schema across current and the next version and make sure that works well. Also you were mentioning something about backups, would they be affected by this change?

Reviewed 3 of 9 files at r1.
Reviewable status: 3 of 9 files reviewed, 3 unresolved discussions (waiting on @manishrjain, @martinmr, and @pawanrawal)

---

query/query3_test.go, line 2159 at r1 (raw file):

	js := processQueryNoErr(t, query)
	require.JSONEq(t, `{"data": {"types":[{"name":"Person",
		"fields":[{"name":"name", "type":"default"}, {"name":"pet", "type":"default"}]}]}}`,

Isn't name of type string as defined outside the types. Why is it being return as default?

---

query/query3_test.go, line 2166 at r1 (raw file):

	query := `schema(type: [Person, Animal]) {}`
	js := processQueryNoErr(t, query)
	require.JSONEq(t, `{"data": {"types":[{"name":"Animal",

Can we have a test which returns scalar fields of type uid and [uid] as well?

---

schema/parse_test.go, line 400 at r1 (raw file):

	reset()
	result, err := Parse(`
		type Person {

Shouldn't this be an error since name isn't defined outside the type definition?

[pullrequest]

Code looks good! Not much feedback to offer

---

Reviewed with ❤️ by PullRequest

[pullrequest]

Is this name still appropriate?

[martinmr]

I didn't change the protobuf so backups are not affected.

I missed the export functionality but I fixed it and the tests.

Users will have to change the export output from a previous version and update the types, though. There's not really a way around this though but I'll make sure this makes it to the release notes for the next version.

Reviewable status: 3 of 11 files reviewed, 4 unresolved discussions (waiting on @manishrjain, @pawanrawal, and @pullrequest[bot])

---

query/query3_test.go, line 2159 at r1 (raw file):

Previously, pawanrawal (Pawan Rawal) wrote…

Isn't name of type string as defined outside the types. Why is it being return as default?

This type should only return the name of the fields but we are using the SchemaUpdate proto for them so they have a type. In reality the type here doesn't matter. Ideally, only the name should be returned for now but I need to look at a way to return the types that doesn't include this unnecessary information. See the TODO above.

I'll fix this in a separate PR since I need to think of a way to do it.

---

query/query3_test.go, line 2166 at r1 (raw file):

Previously, pawanrawal (Pawan Rawal) wrote…

Can we have a test which returns scalar fields of type uid and [uid] as well?

This doesn't make sense. This just returns the type definition. Types don't have the concept of scalar or lists, etc. anymore.
See the comment above on why the type is still showing up in type queries.

---

schema/parse.go, line 352 at r1 (raw file):

Previously, pullrequest[bot] wrote…

Is this name still appropriate?

Yes.

---

schema/parse_test.go, line 400 at r1 (raw file):

Previously, pawanrawal (Pawan Rawal) wrote…

Shouldn't this be an error since name isn't defined outside the type definition?

No. We are not doing this types of checks yet.

[martinmr]

Reviewable status: 3 of 11 files reviewed, 4 unresolved discussions (waiting on @manishrjain, @pawanrawal, and @pullrequest[bot])

---

query/query3_test.go, line 2159 at r1 (raw file):

Previously, martinmr (Martin Martinez Rivera) wrote…

This type should only return the name of the fields but we are using the SchemaUpdate proto for them so they have a type. In reality the type here doesn't matter. Ideally, only the name should be returned for now but I need to look at a way to return the types that doesn't include this unnecessary information. See the TODO above.

I'll fix this in a separate PR since I need to think of a way to do it.

Done.

[MichaelJCompton]

There's also docs to update. I expect it'll be as simple as just removing the types from the examples.

Reviewable status: 3 of 11 files reviewed, 4 unresolved discussions (waiting on @manishrjain, @pawanrawal, and @pullrequest[bot])

[martinmr]

Updated the docs.

Reviewable status: 3 of 13 files reviewed, 4 unresolved discussions (waiting on @danielmai, @manishrjain, @pawanrawal, and @pullrequest[bot])

[pawanrawal]

Reviewable status: 3 of 13 files reviewed, 4 unresolved discussions (waiting on @danielmai, @manishrjain, @pawanrawal, and @pullrequest[bot])

[manishrjain]

Let's not break the existing APIs. Just ignore if the data type is passed. And accept when is it not passed. Do throw a warning that data type should not be passed along with the field in the type.

Reviewable status: 3 of 13 files reviewed, 4 unresolved discussions (waiting on @danielmai, @manishrjain, @pawanrawal, and @pullrequest[bot])

[campoy]

Hey, what's the issue related to this?

Changes to the schema or the query language like this are really really important and shouldn't be done without having a clear design in mind first.

What's the motivation behind this change?

[campoy]

Let's pause this for a second before we change how types work.

[martinmr]

This has already been agreed to. It's part of the conclusions at https://discuss.dgraph.io/t/should-we-remove-the-type-directive/5067/12?u=martinmr