In #3010432: Filtering by referenced entity requires ".uuid" to be specified in filter path expression, we attempted to match the structure of resource objects to acceptable filter paths. This meant that it became possible to filter by a resource object's ID using the id key (and not uuid) and also by an entity reference field's properties by prefixing it with meta.

The remaining disconnect is filtering by type. It's not technically a field on the underlying entity type so it fails to find a matching field. Unlike id, I (believe) we can't simply map the id field name to the bundle field name internally, because a resource type is both entity type + bundle specific.

Perhaps this is a moot point, because filters can only apply to one entity type at a given time (we throw an exception about its "ambiguous" nature if it doesn't).

Comments

gabesullice created an issue. See original summary.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Perhaps this is a moot point, because filters can only apply to one entity type at a given time (we throw an exception about its "ambiguous" nature if it doesn't).

Exactly.

Until we support #2956414: Support mixed-bundle collections (e.g. `/jsonapi/node`), there's no point to this.

IMHO we should merge this into #2956414 and close it as a duplicate.

gabesullice’s picture

gabesullice
Primary language English
commented

Until we support #2956414: Support mixed-bundle collections (e.g. `/jsonapi/node`), there's no point to this.

IMHO we should merge this into #2956414 and close it as a duplicate.

That's not completely true. All related routes are already "mixed bundle collections", so, by extension, it's possible to have a filter across a relationship where the reference points to nodes, but you only want nodes of a certain bundle so you filter by type. Does that make sense?

gabesullice’s picture

gabesullice
Primary language English
commented

it's possible to have a filter across a relationship where the reference points to nodes, but you only want nodes of a certain bundle so you filter by type. Does that make sense?

Currently, you can do this by filtering by ?filter[field_node_ref.node_type.id]={article-uuid}, but I think the less leaky path would be ?filter[field_node_ref.type]=node--article

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#2956414: Support mixed-bundle collections (e.g. `/jsonapi/node`)

You said "all" related routes, but I think you meant some (those for entity_reference fields that allow multiple target bundles). Nonetheless: GREAT point! 👏 I wish I'd thought of that! 😃

I don't think that example has been brought up at #2956414: Support mixed-bundle collections (e.g. `/jsonapi/node`) yet, actually? I think that quite convincingly makes the case for mixed-bundle collections…

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Category: Task » Feature request
effulgentsia’s picture

effulgentsia commented

I'd personally consider this a bug rather than a feature request. The JSON:API spec considers both id and type to be part of a resource's identification, so it seems very odd to be able to filter on one of those but not the other.

I think the less leaky path would be ?filter[field_node_ref.type]=node--article

Yes, I think that would be the natural syntax for it.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

But nothing in the JSON:API spec says you should be able to filter by every "JSON:API field".

effulgentsia’s picture

effulgentsia commented

The JSON:API spec doesn't dictate anything about filtering. But a filtering spec that allows you to filter on one member of a two-part identifier, but not on the other member, seems like a flawed spec, because it privileges one part of the identifier over the other.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Sure. I’m not saying we should not do this. I’m saying this is less important than id, could be added in any release without disruption.

Nothing is broken; a capability is absent.

If you feel strongly this should be classified as a bug report, feel free to change it.

gabesullice’s picture

gabesullice
Primary language English
commented

The capability is present insofar as one is able to query ?filter[field_node_ref.node_type.id]={node_bundle_uuid}. That does match the JSON:API output structure though, so I don't think we need to qualify that as one of the recently discovered "leaky abstractions".

Edit: Actually, that's not possible, because a node bundle is a config entity, which is not queryable.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

So shall we in the mean time throw a 400 response if the user attempts to filter by type?

effulgentsia’s picture

effulgentsia commented

If you feel strongly this should be classified as a bug report, feel free to change it.

Nope. I believe the Fancy Filters spec is where the bug is. I think the spec should require being able to filter by type and id. My hope is that something like the Fancy Filters spec at some point gets some kind of formal approval by the json:api maintainers and increased adoption in the json:api community, and I think some more clarification and strictness about what it requires, allows, and does not allow, will be necessary for that. Of course, I might be wrong about all that. But in any case, based on the current spec, you are correct that Drupal's current implementation is not a bug.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Makes sense, thanks!

gabesullice’s picture

gabesullice
Primary language English
commented

I think some more clarification and strictness about what it requires, allows, and does not allow, will be necessary for that.

+1

rpayanm’s picture

rpayanm
he/him
Primary language Spanish
commented
Project: JSON:API » Drupal core
Version: 8.x-2.x-dev » 8.9.x-dev
Component: Code » jsonapi.module

Moving to Drupal core's issue queue.

I'm working on https://www.drupal.org/project/drupal/issues/3122113

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.