Schema change not allowed from scalar to uid or vice versa while there is data for pred

Dgraph Version: v2.0.0-rc1-514-ga69b22f53

Original Schema:

type Message {
  id: ID!
  to: String!
  from: String!
  message: String!
}

New Schema:

type Message {
  id: ID!
  to: Contact!
  from: Contact!
  message: String!
}
type Contact {
  id: ID!
  name: String!
}

Error Message:

Schema change not allowed from scalar to uid or vice versa while there is data for pred: Message.to

Found my existing data and deleted it with the mutation:

mutation {
  deleteMessage(filter: {id: ["0x2","0x3"]}) {
    numUids
  }
}
  • Tried again to post new schema with same result.
  • Removed to and from predicates from Message type and schema pushed schema successfully. (Although the underlying Dgraph predicates remains)
  • Readded the to and from predicates for the new schema and same error. (as expected due to Dgraph predicates not actually being deleted)
  • Went and looked in Ratel for the Message.to predicate to see if something really was there and didn’t get deleted with my mutation above… Nope, no data there:
    image
    image

IMO, this should be an allowed schema change because there is no data stopping the change. I understand preventing it while there is data for the predicate, but somehow that is not being cleared.

1 Like

@ashishgoswami
This is in error is in dgraph itself . If i DROP DATA then it’s working but with only delete it’s not working.
i reproduced it with following steps in dgraph.

1.Add schema for Message

<Message.from>: string .
<Message.message>: string .
<Message.to>: string .
<dgraph.graphql.schema>: string .
<dgraph.graphql.xid>: string @index(exact) @upsert .

2.Add message

{
  
 set {
     _:message1 <Message.from> "jatin" .
     _:message1 <Message.to> "pawan" .
     _:message1 <Message.message> "hi" .
     _:message1 <dgraph.type> "Message" .
  
  }
  
}

3.Delete message

{
  delete{
       <0x753f> * * .
  }
}

4.Try changing schema: message.from from string type to uid, but got error as below

if i try to DROP data then it works.
Is that expected behaviour?
i guess delete is not cleaning the data properly.

1 Like

Correct

Any update on this? We are using Slash now and running into this error. I can fix it by running some DQL update, but it would be nice to fix it in Slash UI.

EDIT: No I cannot

fix it by running some DQL update

because:

Please note that Slash GraphQL does not allow you to alter the schema or create new predicates via GraphQL±. You will also not be able ta access the /alter endpoint or it’s gRPC equivalent. Please add your schema through the GraphQL endpoint (either via the UI or via the Admin API), before accessing the data with GraphQL±.

https://graphql.dgraph.io/slash-graphql/advanced-queries

We are looking at this along with another issue which allows you to drop a field or drop all the data from the Slash UI itself. @akashjain971 was looking into providing the support in UI.

Alter isn’t exposed to Slash GraphQL users right now because the user while using Alter can end up modifying with the underlying schema in ways that can cause the GraphQL API to break.

1 Like

Related to / Duplicate of Selective drop data for a certain type.

I am working on providing a UI utility in the frontend settings page which will allow users to delete data. Slash will not expose the alter endpoint directly but it will accept delete request on another endpoint and internally call the admin endpoint.

1 Like

Couldn’t we expose the alter endpoint, but limit certain functionalities like modifying GraphQL schema / shutdown and such? I doubt there’s much point in introducing another endpoint, which would have to play catchup to the admin endpoint forever.

1 Like

That would require changes in Dgraph to provide restricted access. Slash already has a new endpoint(/admin/slash) to talk to Dgraph’s admin endpoint for export. I will be using the same endpoint and accept a delete query.

1 Like