We’re overhauling Dgraph’s docs to make them clearer and more approachable. If
you notice any issues during this transition or have suggestions, please
let us know.
Deriving a Dgraph schema from SQL
Before converting the data, the migration tool needs to derive the schema of each predicate. Dgraph follows two simple rules for converting the schema:- For plain attributes, there is usually a one-to-one mapping between a SQL
data type and the Dgraph datatype. For instance, a
Body
column in thePosts
table is of typetext
, and hence, the predicateposts.Body
is of typestring
:posts.Body: string .
- The predicates representing inter-object relationships, like
posts.OwnerUserId.
, simply have the type[uid]
, meaning following the predicate leads us to a set of other objects.
Using the migration tool
You can run the Dgraph migrate tool using this command:-
Create a
config.properties
file that has the following settings and values shouldn’t be in quotes: -
Export the SQL database into
schema.txt
andsql.rdf
file:An output similar to this appears:
If you are connecting to a remote DB hosted on AWS, Google Cloud, and others,
you need to pass the flags
--host
, and --port
. For description of the
various flags in the migration tool, see command line
options.- an RDF file
sql.rdf
containing all the N-Quad entries - a schema file
schema.txt
.
Importing the data
The two files can then be imported into Dgraph using the Dgraph Live Loader or Bulk Loader. Sometimes you might want to customize your schema. For example, you might add an index to a predicate, or change an inter-object predicate (edge) from unidirectional to bidirectional by adding the@reverse
directive. If you would like such customizations, you should do it by
editing the schema file generated by the migration tool before feeding the files
to the Live Loader or Bulk Loader.
To import the data into Dgraph using the Live Loader to Dgraph Zero and Alpha
servers running on the default ports use: