Skip to content
Get help on SlackWatch Sanity demo

Validation error on document schema type in Sanity.io

22 replies
Last updated: Nov 16, 2021
I’m in a pickle. I’m getting a validation error on a document schema type I’ve created. The 
Colors
field looks like this:
{
      name: 'colors',
      type: 'array',
      title: 'Colors',
      of: [{ type: 'colorVariant' }],
      fieldset: 'colors',
    }
so I’m guessing something is wrong in the default validation, as I’m not expecting this to be an array of any strings at all. Anyone knows whats going on?
Bonus info: 
colorVariant
is another document type.
Nov 15, 2021, 7:11 PM
Hey Mads, if your colorVariant is a document, can you try changing your schema to an array of references? Ex:
{
      name: 'colors',
      type: 'array',
      title: 'Colors',
      of: [
        { 
           type: 'reference', 
           to: [
             { type: 'colorVariant' }
           ]
        }
      ],
      fieldset: 'colors',
    }
Nov 15, 2021, 7:40 PM
I tried that. I think the issue might be, that the colorVariant should’ve been an object instead of a document 😬
Nov 15, 2021, 7:52 PM
I think I know what’s wrong now though.
Nov 15, 2021, 7:53 PM
Ah, yeah if you're looking to create them in place and not manage them as separate documents, an object would be the way to go. If you're up to it, you could recreate them as objects using the Mutations API.
Nov 15, 2021, 7:54 PM
Ahh cool! Will look into that 🙂 Thanks!
Nov 15, 2021, 8:39 PM
Shouldn’t I be able to just switch the colorVariant schema type to an object, and then that should work? Looks like they’re already structured as in-place objects:
{
      "_key": "Z2lkOi8vc2hvcGlmeS9Qcm9kdWN0VmFyaWFudC80MTIzOTk0NTc3MzI1Ng==",
      "_type": "colorVariant",
      "colorReference": {
        "_ref": "oxford-navy",
        "_type": "reference"
      },
      "imageBack": {
        "prints": [
          {
            "_key": "SeQJk1IwbN62bsqXBw-H_",
            "height": "150",
            "printType": {
              "value": "back"
            },
            "width": "150",
            "xPos": "50.66%",
            "yPos": "43.94%"
          }
        ],
        "src": {
          "publicId": "151040/back"
        }
      },
      "imageFront": {
        "prints": [
          {
            "_key": "suHp1AGtUCVfNuLErorgd",
            "height": "8",
            "printType": {
              "value": "freetext"
            },
            "width": "55",
            "xPos": "39.11%",
            "yPos": "35.61%"
          },
          {
            "_key": "OQF-LBLTdYnufKqUlpaHw",
            "height": 50,
            "printType": {
              "value": "logo"
            },
            "width": 50,
            "xPos": "62.41%",
            "yPos": "34.39%"
          }
        ],
        "src": {
          "publicId": "151040/front"
        }
      },
      "price": "299.00",
      "selectedOptionsSimplified": [
        "Oxford Navy",
        "XS",
        "Light"
      ],
      "shopifyId": "Z2lkOi8vc2hvcGlmeS9Qcm9kdWN0VmFyaWFudC80MTIzOTk0NTc3MzI1Ng==",
      "sku": "151040",
      "title": "Oxford Navy / XS / Light"
    },
Nov 15, 2021, 8:50 PM
No, 
_type
is immutable so you need to copy those fields over to a new object. If you take a look at that data, you'll find it doesn't have an 
_id
property, so you won't be able to work with it when you go to query your content.
Nov 15, 2021, 8:54 PM
Sorry for the confusion. What I meant was that I should be able to migrate the 
colorVariant
schema from:
export default {
  name: 'colorVariant',
  type: 'document',
  ...
}
to

export default {
  name: 'colorVariant',
  type: 'object',
  ...
}
Nov 15, 2021, 8:57 PM
But I would still need an 
_id
property for the object-version?
Nov 15, 2021, 8:57 PM
Ahhh, got it. Yes, your schema can just be changed the way you mentioned. The data you've already created won't reflect that change, though. That's where the mutations come in. The 
_id
property is an identifier added by the Studio, you don't need to specify in it your schema, but you will need to add one if you mutated your existing content into objects.
Nov 15, 2021, 9:01 PM
All this data is something I’ve added during a custom import script, so I think where I went wrong was that I took the approach of using in place objects, instead of documents, but I defined the schema as being a document instead of an object.
Nov 15, 2021, 9:07 PM
So the 
colorVariant
was never a document, but actually an object. Do I still need to make the mutation-exercise in that case?
Nov 15, 2021, 9:09 PM
Basically, it seems to be working fine in both the graphql API and the Sanity UI. However, I’m getting a validation error that causes me to not be able to publish. I’m not sure what I’m missing. I get no pointers but this:
Nov 15, 2021, 9:23 PM
And this:
Nov 15, 2021, 9:24 PM
But when I click those validation errors, I’m being led to the object-editor, but there seems to be no validation errors.
Nov 15, 2021, 9:24 PM
You're likely getting this because of the missing 
_id
property.
Nov 15, 2021, 9:28 PM
Alright, so the objects need the _id property
Nov 15, 2021, 9:28 PM
You're likely getting this because of the missing 
_id
property.
Nov 15, 2021, 9:28 PM
Is there any way to disable the validation temporarily?
Nov 15, 2021, 9:46 PM
If you set 
validation: false
at the top level of the schema, it should disable it .
Nov 15, 2021, 11:03 PM
I think there’s definitely a bug in Sanity. I’ve now updated my 
colorVariant
objects to also hold a unique 
_id
, but I still get the above error.
Nov 16, 2021, 7:35 AM
Nope, turns out the issue was in another schema that was nested inside the 
colorVariant
type. Reason being it using a custom input component, that was returning the wrong types the schema was expecting 🙂 Solved!
Nov 16, 2021, 9:45 AM

Sanity– build remarkable experiences at scale

The Sanity Composable Content Cloud is the headless CMS that treats content as data to power your digital business. Free to get started, and pay-as-you-go on all plans.

Get startedWatch demo

Was this answer helpful?