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

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.

Not working query in v3 (note

season

field just has

_ref

and

_type

properties):

When I rename

season

, I get both the reference fields and the field from the referenced entity:

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.

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).

Not sure which API version v2 is using, but using

v2023-01-19

reproduces the issue in v3

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.

Thanks for the tip.

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!

Try moving your … to the top, might be overwriting

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!

Doesn't seem to make a difference, unfortunately.

Sure you moved the correct “…” ? Try removing both you have in your query.