Dgraph schema alteration good practices

Hi, i would like to discuss about how a Schema should be managed.

related to #3645

In a container environment where the app is replicated and often start/shutdown concurrently it would not be wise to alter the schema on start as Dgraph doesn’t seem to check for existing predicates and just override, is there some practices/solutions for this ?

The first thing coming to my mind would be to setup a repository dedicated only to manage the entire Dgraph schema for my product/app thus becoming available to a CI/CD controlled environment. I’d like some community advice on this subject, how do you manage you schemas ? how would you do it ? what are the alternatives ?

Thanks.

Hi @Sceat, what language is your Dgraph client?

If you’re using the Go Dgraph client, a suggestion is that you can use Dgman to manage your schemas. It has a CreateSchema function that will create and detect existing or duplicate predicates in your schema, preventing overwrites and reindexing your predicates.

Hi, i’m using the javascript client, if we can actually pull the whole schema from Dgrpah, detecting conflict is indeed a good solution

Hi @Sceat, starting from Dgraph v20.03.0, background indexing has been introduced. It only updates the predicates and its indexes if it is different from the existing Dgraph schema while mutations and queries continue to work.

Here an example from JS client:

const schema = "name: string @index(exact) .";
const op = new dgraph.Operation();
op.setSchema(schema);
op.setRunInBackground(true);
await dgraphClient.alter(op);