✨Discover storytelling in the AI age with Pixar's Matthew Luhn at Sanity Connect, May 8th—register now

Changes in syntax for references in v3 causing issues with field population.

12 replies
Last updated: Jan 20, 2023
Has anything changed with regard to the
{...}
syntax for references in v3? I have a query that is expecting the all the fields of a reference to be populated, but all that is returned is
_ref
and
_type
. Strangely, if I rename the field in the query, I get both the reference field, and the renamed field with all the fields populated. Behavior does not happen in v2 for the same query.
Jan 20, 2023, 12:51 AM
Not working query in v3 (note
season
field just has
_ref
and
_type
properties):
Jan 20, 2023, 12:52 AM
When I rename
season
, I get both the reference fields and the field from the referenced entity:
Jan 20, 2023, 12:53 AM
So both of those are v3 screenshots, I'm assuming in Vision?
And v2 does what for the two scenarios of keeping the original key name but pointing to the dereferenced version and renaming it?

Are they both using the same API when testing? I only ask because I have whatever is the most recent one picked but I swear sometimes the dropdown skips back to API v1.
Jan 20, 2023, 2:50 AM
Correct, v3. In v2, for the first screenshot,
season
is fully populated wih its field. The second screenshot is the same in v2 (
season
has the
_ref
and
_type
fields, renamed field is populated).
Jan 20, 2023, 3:43 AM
Not sure which API version v2 is using, but using
v2023-01-19
reproduces the issue in v3
Jan 20, 2023, 3:44 AM
Ah, v2 is using api v1, and when I switch v3 to use api v1, I get the behavior I want (
season
being fully populated). I'll make sure I'm using API v1.
Jan 20, 2023, 3:48 AM
user S
Thanks for the tip.
Jan 20, 2023, 3:49 AM
That's all very interesting, genuinely. Usually when I make up names for the things I am projecting they are fairly different. Like instead of thing[]-> I will say "listOfThings" : thing[] and so on....or I used it directly.
I was kind of curious if it had anything to do with how the query parser handled it being the same name, like if it got "confused" with an alias-like key name that happened to be one that existed.

I am wondering if anyone on the
groq channel might have more insight overall.
It's my understanding that the v1 could be pretty limiting for other things you might want to accomplish beyond matching the desired behavior for this one use case, so it could be worth it to pre-empt issues with, say, missing functions or other unanticipated return formats and seeing if there's a solution that lets you stay put on a more recent date-based API version.

(Hopefully that was lucid, I am off to bed)

Glad all is well for the time being, though!
Jan 20, 2023, 4:41 AM
Try moving your … to the top, might be overwriting
Jan 20, 2023, 9:34 AM
Interesting! I didn't realize there was a difference when ordering. I always just stuck it at the end to do it Gilligan's Island -style ...."and the rest" 🙂
That's good to know!
Jan 20, 2023, 3:15 PM
user A
Doesn't seem to make a difference, unfortunately.
Jan 20, 2023, 6:38 PM
Sure you moved the correct “…” ? Try removing both you have in your query.
Jan 20, 2023, 7:29 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?