Need guidance on removing a field from the schema in an app using Sanity.io

11 replies
Last updated: Feb 8, 2024
Hey all, I have an app that is already being used. There's a field in some of the documents and this field is being removed from our schema now. Is there anything I need to do when it comes to the data that had been added already? Could someone point me to a place in the docs where I can find more information about it? Thanks!
AI Update

Good question! When you remove a field from your Sanity schema, the existing data in documents that have that field will not be automatically deleted. This is actually a feature designed to prevent unintended data loss.

What happens to the existing data?

The data remains in your documents in the Content Lake. Sanity treats schema changes as non-destructive by default - changing your schema doesn't cascade changes to existing content. This helps prevent breakage for applications that might still rely on that data.

What you should consider doing:

  1. Mark the field as deprecated first (optional but recommended for production projects)

    You can use the deprecated property in your schema to mark fields that shouldn't be used anymore:

    defineField({
      name: 'oldFieldName',
      type: 'string',
      deprecated: {
        reason: 'This field is no longer used'
      },
      readOnly: true // prevents further edits
    })
  2. Decide if you need to clean up the data

    You have a few options:

  3. Run a migration to remove the data (if needed)

    If you want to actually remove the field data from existing documents, you can create a migration script using sanity migration create and use the unset() helper function.

Where to find more information:

The main documentation page you want is: Migrating your schema and content

Also helpful:

The short version: you're safe to remove the field from your schema without worrying about data loss. The old data will just sit there harmlessly unless you explicitly remove it with a migration.

This should help!
That's really helpful! Thanks
user M
!
I think I celebrated too early 😄 . I just tested this on my end and it doesn't seem to show anything on a field at least:
title: "Title2",
  name: "title2",
  type: "string",
  deprecated: {
    reason: 'Title2 not used anymore.'
  },
  readOnly: true // to prevent further edits
Even thought it seems to prevent the user from typing, it still allows them to focus on the input and doesn't give any feedback, which doesn't seem to be a good user experience.
What version of the Studio are you on?
3.24.1
Ah yeah, this just shipped this week, so give updating a go.
Ah, got it. I'll keep that in mind then...I'll push for the field removal though, since it's something that is probably more aligned with what the client wants to. Thanks for the help 🤝
If you go that route just repurpose this script.
How does that
--with-user-token
associate with my account? I'm getting an insufficient permissions error:
responseBody: '{\n' +
    '  "error": {\n' +
    '    "description": "Mutation failed: Insufficient permissions; permission \\"update\\" required",\n' +
    '    "items": [\n' +
    '      {\n' +
    '        "error": {\n' +
    '          "description": "Insufficient permissions; permission \\"update\\" required",\n' +
    '          "permission": "update",\n' +
    '          "type": "insufficientPermissionsError"\n' +
    '        },\n' +
    '        "index": 0\n' +
    '      }\n' +
    '    ],\n' +
    '    "type": "mutationError"\n' +
    '  }\n' +
    '}',
I assume I should create a token somewhere to attach it? I'm logged in my organization via sso if it matters.
I managed to fix that by creating a token in the environment and providing that token once I'm creating the client. That works. Thanks!
It could have been that you were logged into a different account in the CLI. Using different providers creates different accounts.

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?