Given the very common schema:
type User {
username: String! @id
name: String
}
I had a use case today where a user needed to change his username. This is very uncommon occurrence, but the need was legitimate.
I first thought, that this was going to be a nightmare because everything is linked to the username. In my schema, users are linked to their settings, to their linked Contact, from all of their access rights, etc.
After going over what all it would take to do this many times in my head, it dawned on me, that nothing is actually linked to the “User.username” but instead it is linked to the uid. The uid is not available on the GraphQL endpoint for any type that uses XIDs (@id directive). But nonetheless the uid DOES still exist at the DQL level. So without having the field settable in the generated schema, I had to set it via DQL with an upsert.
I think we should make it possible to update the XID from the graphql endpoint as well. It will need an extra step of logic to check for any existing uid that is mapped to the new XID already, and the update needs to be for a single node only. This might require a new mutation because the standard updateType mutation allows filtering and updating multiple nodes at once and not just a single node. So complicated yes, but I would find value in this feature.
I could see this as needed for other use cases of XIDs as well and not just the username situation that I found myself in today.