Problem/Motivation
If an entity query is run against a standard, non-DER, entity reference field, something is still trying to attach the _int logic to the query.
This query, for instance, given a base field called normal_reference:
$result = \Drupal::entityTypeManager()->getStorage('entity_test_mul')->getQuery()
->condition('normal_reference.entity:user.status', 1)
->execute();
produces the following error:
Column not found: 1054 Unknown column 'entity_test_mul_property_data.normal_reference_int' in 'on clause': SELECT base_table.id AS id, base_table.id AS base_table_id
FROM
{entity_test_mul} base_table
INNER JOIN {entity_test_mul_property_data} entity_test_mul_property_data ON entity_test_mul_property_data.id = base_table.id
LEFT OUTER JOIN {users} users ON users.uid = entity_test_mul_property_data.normal_reference_int
INNER JOIN {users_field_data} users_field_data ON users_field_data.uid = users.uid
WHERE users_field_data.status = :db_condition_placeholder_0; Array
(
[:db_condition_placeholder_0] => 1
)
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #25 | 2908109-25.patch | 6.54 KB | jhedstrom |
| #16 | 2908109-16-TEST-ONLY.patch | 5.13 KB | jhedstrom |
Comments
Comment #2
jhedstromThis demonstrates the issue. If the same test is run w/o DER enabled, this passes.
Comment #4
jhedstromThis logic is appending
_intfor any entity reference field. Not sure how to fix as this is sitting bellow the field API level where we'd know whether this was a DER field or not...Comment #5
jibranWoW! I'd ping @Berdir to get some ideas around this.
Comment #6
jhedstromHere's a demonstration of how we could resolve this with the attached patch for core. Not sure how readily we could get that in, so posting here for thoughts. This will fail on the test bots since they won't apply the core patch :)
Comment #9
jibranI think this makes sense let's create a core issue.
Comment #10
jhedstromInterestingly enough, this works in core 8.2.x. I'm currently running git bisect to figure out what changed.
I'll open up a core issue shortly.
Comment #11
jhedstromAh, this is what changed between 8.2 and 8.4/8.5: #2424791: Entity query hardcodes entity_reference and entity specifier.
Comment #12
jhedstromI've opened #2908605: Pass field storage to Tables::addNextBaseField().
Comment #13
jhedstromAh, that's why it "works" in 8.2.x--the
addNextBaseTablemethod didn't exist then, so the override we have here was never triggered.Comment #14
jibranIs it also broken for entity reference configurable fields?
Comment #15
jibranComment #16
jhedstromIt appears to be. I've added a normal entity reference configurable field test here. It fails in the same manner, and passes with the proposed core fix.
Comment #19
jibranWe should add
is_nullcheck here. I think we should also fix for #2909425: Add the $field_storage parameter to Tables::addNextBaseTable at the same time. Add the fourth optional param if it'sNULLthen usefunc_get_arg(3)and if it is stillNULLthen don't add$field_storagecheck.Comment #20
jhedstromI made the entire conditional dependent on the field storage, since otherwise, this error will still be present on sites that somehow this method gets called for that aren't up-to-date and passing in the field storage...
Comment #22
jhedstromThis fixes some issues with the tests.
Comment #24
jibran#2909425: Add the $field_storage parameter to Tables::addNextBaseTable is in so we have to fix it for both core version(8.4.x and 8.5.x) now.
Comment #25
jhedstromThis should do it I think :)
Comment #27
jibranThanks, for the fix. Committed and pushed to 8.x-2.x. I'll create a new release soon.