Linking types to other Types not working

Using the schema below, I’m unable to set a Type’s field to be another Type. So Childs’s sibling field should be Sibling, but it won’t stick that way. Ratel sends a request to /alter, but the logs show that it gets ignored. Then in the UI, the dropdown for picking the type reverts to Child. What am I missing? I’m on v1.1.1.

Ratel alter request body:

     type <Child> {
            <name>: <int>
<sibling>: <Sibling>
<child_order>: <int>
          }

Logs:

server_1  | I0113 21:27:10.812240       1 server.go:80] Received ALTER op: schema:"\n          type <Child> {\n            <name>: <int>\n<sibling>: <Sibling>\n<child_order>: <int>\n          }\n        "
server_1  | W0113 21:27:10.815204       1 parse.go:402] Type declaration for type Child includes deprecated information about field type for field name which will be ignored.
server_1  | W0113 21:27:10.815313       1 parse.go:402] Type declaration for type Child includes deprecated information about field type for field sibling which will be ignored.
server_1  | W0113 21:27:10.815334       1 parse.go:402] Type declaration for type Child includes deprecated information about field type for field child_order which will be ignored.
server_1  | I0113 21:27:10.815359       1 server.go:206] Got schema: &{Preds:[] Types:[type_name:"Child" fields:<predicate:"name" > fields:<predicate:"sibling" > fields:<predicate:"child_order" > ]}
server_1  | I0113 21:27:10.820385       1 server.go:211] ALTER op: schema:"\n          type <Child> {\n            <name>: <int>\n<sibling>: <Sibling>\n<child_order>: <int>\n          }\n        "  done

Schema:

{
  "data": {
    "schema": [
      {
        "predicate": "child",
        "type": "uid",
        "reverse": true
      },
      {
        "predicate": "child_order",
        "type": "int",
        "index": true,
        "tokenizer": [
          "int"
        ]
      },
      {
        "predicate": "dgraph.type",
        "type": "string",
        "index": true,
        "tokenizer": [
          "exact"
        ],
        "list": true
      },
      {
        "predicate": "name",
        "type": "int"
      },
      {
        "predicate": "sibling",
        "type": "uid",
        "reverse": true,
        "list": true
      }
    ],
    "types": [
      {
        "fields": [
          {
            "name": "name"
          },
          {
            "name": "sibling"
          },
          {
            "name": "child_order"
          }
        ],
        "name": "Child"
      },
      {
        "fields": [
          {
            "name": "child"
          },
          {
            "name": "name"
          }
        ],
        "name": "Parent"
      },
      {
        "fields": [
          {
            "name": "name"
          }
        ],
        "name": "Sibling"
      }
    ]
  },
  "extensions": {
    "server_latency": {
      "parsing_ns": 17700,
      "processing_ns": 323000,
      "assign_timestamp_ns": 3085800,
      "total_ns": 4118700
    },
    "txn": {
      "start_ts": 10216
    },
    "metrics": {}
  }
}

Types and Schema are different things in the Schema context. In the latest releases, the Type System got simpler. So there’s no need to add types to a field in the Type Schema. You can control it from the Schema itself.

Also, it is not possible to reassign a field to another type without dropping it.

e.g:

   type Child {
            name
            sibling
            child_order
          }

<name>: String .
<sibling>: [uid] .
<child_order>: int .

So is Ratel behind and maybe will be updated in the future to match this? Why does it offer the choice to choose another Type for boss_of in this case? (Screen shot of Person/boss_of from tour of dgraph)

Yes, it will be.

This was the old behavior, after some internal discussions, we realize that these parameters are not being checked and have no technical reasons to be there. They would only be aesthetic and confuses the people about the real purpose of the Type System.

You might also want to try our GraphQL support https://graphql.dgraph.io/ that does handle types in the way you are requiring.

It’s in our current release candidate and will be released as part of Dgraph 1.2