Closed (fixed)
Project:
JSON:API
Version:
8.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
16 Nov 2018 at 21:38 UTC
Updated:
26 Dec 2019 at 00:39 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
olexyy.mails@gmail.com commentedLooks like logic does not includes custom entity ref implementation, where entityr ref is not in separate table but in one main table of entity and is null.
Comment #3
olexyy.mails@gmail.com commentedComment #4
olexyy.mails@gmail.com commentedThis additional check in patch make it for me.
Comment #5
olexyy.mails@gmail.com commentedComment #6
olexyy.mails@gmail.com commentedComment #8
olexyy.mails@gmail.com commentedPatch applied by composer...
Comment #9
olexyy.mails@gmail.com commentedComment #10
olexyy.mails@gmail.com commentedComment #11
olexyy.mails@gmail.com commentedComment #13
olexyy.mails@gmail.com commentedComment #15
olexyy.mails@gmail.com commentedWell , I did it through `git diff`, composer applies it, so anyone who suffers, have soution...
Comment #16
olexyy.mails@gmail.com commentedComment #17
wim leersThanks for reporting this problem and even working on a patch already! 🙏 👌
Can you share this base field definition? I'd love to reproduce this locally :)
Comment #18
olexyy.mails@gmail.com commentedThis emulates picture like on D7 user (no separate field|table)
Comment #19
olexyy.mails@gmail.com commentedCardinality is 1 by default.
Comment #20
olexyy.mails@gmail.com commentedComment #21
olexyy.mails@gmail.com commentedTell me why patch is not applies, I followed naming convention, this is strict copy of `git diff`, composer installs it ...
Comment #22
gabesullice@olexyy.mails@gmail.com, did you generate the patch from the latest code on the JSON:API 8.x-2.x-dev branch? Perhaps you used the 1.x branch by accident?
Comment #23
keesee commentedI am also have this issue. Tried both 8.2.0.x (rc2) and the dev release
I have one custom entity referencing another. The referenced entity has a carnality of -1. both are generated with drupal generate:entity:content
any patches out there for this issue yet?
Comment #24
keesee commentedthe referenced entity. I mentioned in #23
Comment #25
wim leersReproduced using #20!
Comment #26
wim leersThe root cause is that in this case, there is a
FileFieldItemListcontaining one value, aImageItemobject whoseisEmpty()returns TRUE, yet it does contain a value:This matches what's stored in the database:

Whereas configurable entity reference fields in general end up with
FieldItemList::$list = [].So this appears to be a bug in how base fields versus configurable fields are handled. Core doesn't have any base entity reference fields that are optional. If the field was required, this wouldn't be a problem (then the value wouldn't be empty).
On the one hand I want to write test coverage for this, on the other hand it's so much overhead for something that is as trivial to fix as this.
Comment #27
wim leersThis then actually allows a slight simplification in the loop's body.
Comment #28
wim leersAlso: it's pretty cool to see that there are some people out there writing custom entity types! 🤘 🎉
Comment #29
lawxen commented3014380-27.patch works for me, Thanks.
The bug happened on request commerce module's entity: commerce_order /jsonapi/commerce_order/default .
Because all our commerce_order's field billing_profile is empty (We post commerce_order by rest, and get commerce_order by jsonapi).
The field billing_profile's definition is here: https://cgit.drupalcode.org/commerce/tree/modules/order/src/Entity/Order... .
Comment #30
wim leers@caseylau Woot, thank you so much for confirming this! 🎉
I'm pretty sure that @gabesullice or @e0ipso will now be happy to RTBC and commit this.
Comment #31
gabesullice@olexyy.mails@gmail.com, can you confirm that this fixes the problem for you? If so, mark this as RTBC and I'll commit it :)Welp! @caseylau just did exactly what I needed! LGTM!
Comment #33
gabesulliceComment #34
wim leersLooks like a duplicate of this was reported: #3019329: 500 error is thrown while pushing the node creation.
Comment #35
npralhad commentedComment #36
gabesullice@npralhad, this issue has already been marked "Fixed". Can you open a new issue (a "followup" if need be) and explain your patch? Thank you!
Comment #37
wim leersUncrediting @npralhad (uploading a patch to a fixed issue automatically grants credit).
Comment #38
wim leers@npralhad apparently just re-uploaded their patch from #3019329-2: 500 error is thrown while pushing the node creation here.
Comment #39
mstef commentedIs there a patch or fix for 1.x?
Comment #40
mstef commentedHere's a patch that applies against 1.24, in case any one needs it.
Comment #41
mstef commentedDo you want to get my last patch in for 1.x? If not, you can re-close this.
Comment #42
wim leersPinged @e0ipso and @gabesullice to get their thoughts. In any case, we strongly recommend you to update to JSON:API 2.x — but we understand this is not always possible given project constraints.
Comment #43
gabesulliceI have no objections to backporting this. I have a slight preference for waiting until we have a few issues to commit so that it makes sense to make another release. That'd discourage running the dev branch in production. Composer makes it easy to automatically apply the patch in #40 until that time.
Comment #44
wim leersComment #45
gerzenstl commentedI can confirm patch from #38 works
My setup:
Drupal: 8.6.9
jsonapi: 1.24
jsonapi_extras: 2.15
Given project constraints we're looking for a good way to upgrade to JSON:API 2.x.
Comment #46
wim leersAt this point, we want people to move over to Drupal core's JSON:API. This is not even a critical bugfix, so backporting is hard to justify by now.