\Drupal\jsonapi\Context\FieldResolver::resolveInternalEntityQueryPath accepts a resource type object, but later wraps it as an array. The resolveInternalEntityQueryPath should accept an array of resource types by default. This helps unblock contributed projects that interact with JSON:API to extend its functionality such as JSON:API Cross Bundles.

The method was refactored in #3070204: Refactor the JSON:API FieldResolver to use a resource type instead of an entity type ID and bundle ID pair to accept a resource type value. Prior to that issue, the method received an entity type ID and bundle which is converted to a resource type and wrapped in an array. This issue is a follow up to rectify the fact we cannot pass an array of resource types and receive the internal entity query path.

Support for passing in multiple resource types unblocks performing entity queries across bundles with JSON:API.

Original summary

This is a major impediment for support for mixed-bundle collections (https://www.drupal.org/project/jsonapi_cross_bundles) and sortable/filterable/paginated related collection routes. Support for the latter would enable us to have automatic support for "reverse" related routes.

CommentFileSizeAuthor
#11 3031173-11.patch4.46 KBmglaman
#10 3031173-10.patch2.59 KBmglaman

Comments

gabesullice created an issue. See original summary.

gabesullice’s picture

gabesullice
Primary language English
commented
Related issues: +#3070204: Refactor the JSON:API FieldResolver to use a resource type instead of an entity type ID and bundle ID pair
gabesullice’s picture

gabesullice
Primary language English
commented
Title: FieldResolver::resolveInternalEntityQueryPath should accept an array of resource types, not a single entity type ID and bundle » [PP-1] FieldResolver::resolveInternalEntityQueryPath should accept an array of resource types, not a single entity type ID and bundle
Status: Active » Postponed

Postponing this on a prerequisite refactoring: #3070204: Refactor the JSON:API FieldResolver to use a resource type instead of an entity type ID and bundle ID pair

gabesullice’s picture

gabesullice
Primary language English
commented
Title: [PP-1] FieldResolver::resolveInternalEntityQueryPath should accept an array of resource types, not a single entity type ID and bundle » [PP-1] FieldResolver::resolveInternalEntityQueryPath should accept an array of resource types, not a single resource type
gabesullice’s picture

gabesullice
Primary language English
commented
Project: JSON:API » Drupal core
Version: 8.x-2.x-dev » 8.8.x-dev
Component: Code » jsonapi.module
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: [PP-1] FieldResolver::resolveInternalEntityQueryPath should accept an array of resource types, not a single resource type » FieldResolver::resolveInternalEntityQueryPath should accept an array of resource types, not a single resource type
Status: Postponed » Active

#3070204: Refactor the JSON:API FieldResolver to use a resource type instead of an entity type ID and bundle ID pair landed! 🥳

jibran’s picture

jibran
he/him
Primary language Urdu
Location Toronto, Canada
commented
Issue tags: +Needs issue summary update

This is a contrib blocker, right?

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Issue summary: View changes
Issue tags: +Contributed project blocker

It is.

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

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

mglaman’s picture

mglaman
Primary language English
Location WI, USA
commented
Status: Active » Needs review
StatusFileSize
new 3031173-10.patch2.59 KB

Trying to remember the initial discussions for this. Would it be to allow passing in resource types for each Node bundle and ensuring the internal field path exists?

Here is a patch to at least rekindle the discussion.

mglaman’s picture

mglaman
Primary language English
Location WI, USA
commented
StatusFileSize
new 3031173-11.patch4.46 KB

Here's an updated patch to include a test.

mglaman’s picture

mglaman
Primary language English
Location WI, USA
commented
Issue summary: View changes
Issue tags: -Needs issue summary update

Updated the issue summary.

mglaman’s picture

mglaman
Primary language English
Location WI, USA
commented
Assigned: Unassigned » mglaman

Discussed with @gabesullice in Slack. We can use this not just for the jsonapi_cross_bundle module but also related routes already provided.

For example, /jsonapi/user/user/{uuid}/publicationscould be a mixed-bundle relationship of nodes. I'll work on a quick test to check if running includes on related routes works with or without this patch.

jibran’s picture

jibran
he/him
Primary language Urdu
Location Toronto, Canada
commented

IS looks good. Thanks for the update.

+++ b/core/modules/jsonapi/src/Context/FieldResolver.php
@@ -272,9 +272,21 @@ public function resolveInternalEntityQueryPath($resource_type, $external_field_n
+    elseif (is_array($resource_type)) {
...
     elseif (!$resource_type instanceof ResourceType) {
...
+    else {
...
+      $resource_types = [$resource_type];

Let's simplify this this and DRY at the same time.

if (!is_array($resource_type)) {
      /* @var \Drupal\jsonapi\ResourceType\ResourceType[] $resource_types */
      $resource_types = [$resource_type];
}

array map/walk $resource_types and throw exception. Do we need tests the exception?

mglaman’s picture

mglaman
Primary language English
Location WI, USA
commented 
array map/walk $resource_types and throw exception. Do we need tests the exception?

If a map/walk necessary? We're not manipulating values, so a foreach is fine. JSON:API does use an assert for checking all items in an array are of a type, so maybe we can use that. I don't think JSON:API tests any of its exceptions like that.

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.

bbrala’s picture

bbrala
Location Netherlands
commented
Status: Needs review » Needs work

Seems there is some open feedback so moving it back to needs work. Seems like a usefull change that opens up a few helpfull possibilities.

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.