👋 Next.js Conf 2024: Come build, party, run, and connect with us! See all events

Understanding attribute limits and references in Sanity.io schemas

15 replies
Last updated: May 2, 2022
I'm a little confused by how the attributes limit is determined. Really, I'm just a little confused what an attribute actually is. Let's say I have and object called
nameFull
and it has two string fields
firstname
and
lastName
This object is in my document twice, one reference has the name
yourName
and the other has the name
yourFathersName
. How many unique attributes would this be? I'll show a rough example:
Document:

{
type: "document",
name: "familyMembers",
fields: [
  {
    name: "yourName",
    type: "nameFull"
  },
  {
    name: "yourFathersName",
    type: "nameFull"
  },
]
}
nameFull Object:

{
type: "object",
name: "nameFull",
fields: [
  {
    name: "firstName",
    type: "string"
  },
  {
    name: "lastName",
    type: "string"
  }
]
}
May 2, 2022, 4:02 PM
hmmm - references are a way of linking documents. Each document existing on its own.
objects* like this are re-usable prescribed sets of data. If you wanted each ‘name’ to be a person document with nicely mapped relations you would need to change this into a document of its own or add your own additional fields to assign IDs or check for duplicates in each document where you use the object.
May 2, 2022, 4:38 PM
If you’re doing something like a family tree, maybe take out the “father/mother name” fields and use references between each person document. Then you can create a nice set of relationships between each person.
bit of pseudocode - messy off the top of my head, some strings implied…

// people schema
{
name: "person"
type: "document"
fields: [
{name: "name", type: "array", "of": [
{name: "namefield", type: "object": "fields": [
{name: "nametype", type: "array": of: [first, surname, middle, maiden, nickname, other]}, {name: "name", type: "string"}
]}]...
// then add another object of references to other people as relatives
{name: "relations", type: "object", fields: [
{name: "relation", type: "array", of: [mom, dad, sib, spouse, etc]},
{
      title: 'Relative',
      name: 'relative',
      type: 'reference',
      to: [{type: 'person'}]
}]}...
I like to get a visual of the data layout I want to design and then use different arrays and objects to work the actual schema into this visual model. This visualization is pretty easy with family trees.
May 2, 2022, 5:05 PM
you can add various flags for genetic vs marriage relations and keep going with as much detail as you’d like. Fun project.
May 2, 2022, 5:06 PM
You should check out and repost this on content-modeling & content-strategy for possibly a bit more community feedback with examples. Keep it up!
May 2, 2022, 5:34 PM
ah good question, I’ll dig into it a bit more thanks!
May 2, 2022, 5:50 PM
my gut feeling is that since each of those imported objects doesn’t have a unique ID on its own, they’ll count toward the attribute limit. And this is what I was alluding to in my brainstorm using arrays and references to both cut down on attribute limits and provide improved relationship data (something like a grandfather with a few children who have a few children each can get out of hand pretty fast - if not with attributes then with 12+1 versions of the grandfather’s name that are otherwise unrelated in the dataset)
May 2, 2022, 5:59 PM
And I believe this is generally what the documentation’s suggestions on cutting down on attribute limits are referring to as well. I’m just not absolutely certain off-hand what the differences in attribute limits might be between your imported object fields and something like block text, which in it its own document is an imported array of objects, each with their own defined content types.
May 2, 2022, 6:03 PM
To my knowledge, generally focussing on meaning, not presentation like my example hints at is a best practice both for easier organization and keeping attribute limits to a minimum. I’m not sure what your ultimate use-case my be, but I have yet to see community or team plan projects come up against attribute limits since starting here.
May 2, 2022, 6:08 PM
I think in your example use case, I would advise nesting name fields in each person document and then creating an array of references between each person to keep overall attributes from becoming exponential unique values. It is a little more work up front to plan but with the benefit of saving a ton of editing time and avoiding something like grandpa “User” being listed 12 additional times for himself, his kids, and his grandkids.
May 2, 2022, 6:11 PM
personDoc.nameObject.first.last
personDoc.relatedRef.personDoc
then use queries to get the referenced data from each referenced document
May 2, 2022, 6:14 PM
but this is something that would be WAY easier to whiteboard ^_^
May 2, 2022, 6:15 PM
That’s how I think about it. If you have a lot of fields, the goal is to keep those unique object values to a minimum, and you would best do this by thinking of it as primitive datatypes with as many arrays and references as possible.
May 2, 2022, 6:18 PM
Bonus: this also makes queries and searching immensely easier.
May 2, 2022, 6:18 PM
An attribute is a unique combination of properties and datatypes and must hold content to count toward your limit. In your first example, I count 8 attributes (assuming they all have data):

yourName
yourName.nameFull
yourName.nameFull.firstName
yourName.nameFull.lastName
yourFathersName
yourFathersName.nameFull
yourFathersName.nameFull.firstName
yourFathersName.nameFull.lastName
Block content can impact the attribute count quite a bit, though it’s often justified given its return. Duplicated fields, including field level translations, can drive the attribute count up a lot.
May 2, 2022, 6:21 PM
Focussing on using references, you can see how much this cuts down on attributes on its own as an array of references just copies the referenced document ID instead of all of the subsequent values:(“article” document with a referenced “category” document)
May 2, 2022, 6:25 PM

Sanity– build remarkable experiences at scale

Sanity is a modern headless CMS that treats content as data to power your digital business. Free to get started, and pay-as-you-go on all plans.

Was this answer helpful?