Schema exports predicates that cannot be re-imported.

[danielmai]

If you suspect this could be a bug, follow the template.

• What version of Dgraph are you using?
  master (a1e3681) and v1.0.16.

• Have you tried reproducing the issue with latest release?
  Yes

• Steps to reproduce the issue (command/config used to run Dgraph).

1. Run Dgraph cluster
2. Run a mutation to a predicate with only numbers in the name, e.g. <123>:

{
  set {
    _:n <123> "test"^^<xs:string> .
  }
}

3. Run export curl localhost:8080/admin/export.

4. The schema file contents look like this:

$ zcat g01.schema.gz 
123:string . 

5. Run live loader with the exported data and see this error:

$ dgraph live -f g01.rdf.gz -s g01.schema.gz -a localhost:9080 -z localhost:5080
[Decoder]: Using assembly version of decoder
I0722 14:53:03.072148    9624 init.go:93] 

Dgraph version   : v1.0.12-rc3-613-ga1e368193
Commit SHA-1     : a1e368193
Commit timestamp : 2019-07-22 10:46:41 -0700
Branch           : master
Go version       : go1.12.5

For Dgraph official documentation, visit https://docs.dgraph.io.
For discussions about Dgraph     , visit https://discuss.dgraph.io.
To say hi to the community       , visit https://dgraph.slack.com.

Licensed variously under the Apache Public License 2.0 and Dgraph Community License.
Copyright 2015-2018 Dgraph Labs, Inc.



Running transaction with dgraph endpoint: 127.0.0.1:9080

Processing schema file "g01.schema.gz"
Error while processing schema file "g01.schema.gz": rpc error: code = Unknown desc = while lexing 123:default . 
dgraph.type:[string] @index(exact) . 
 at line 1 column 0: Invalid schema. Unexpected 1

• Expected behaviour and actual result.

I expect that exported data should be able to be re-imported as-is with live loader, bulk loader, or regular client alter and mutate operations.

A fix for this is to export the schema file with predicate names like 123 surrounded with angle brackets to escape them. we do for i18n predicates <>:

<123>:string .