I was able to figure this out with your feedback digging through web/core/lib/Drupal/Core/Entity/Query/Sql/Tables.php with xdebug. The end string I used was field_custom.reference.reference__entity:node.field_number
When this is broken in to specifiers for join tables:
- field_custom is used as the base table
- Although the main property is null, since the next specifier reference is a real column it takes precedence and the key is advanced
- reference__entity:node is next and is used as the relationship_specifier. Since it's in the property definitions and is type DataReferenceDefinitionInterface, it joins the node table.
- Works as expected from here with field_number
I'm going to mark this works as designed, but it would be great to get this documented in some examples somewhere. I'm not sure the best place to put it. A new page under https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → ?
mrconnerton → created an issue.
Getting closer. that produces an error SQLSTATE[42S22]: Column not found: 1054 Unknown column 'node__field_custom.field_custom_'. Running through it with xdebug, I see that Drupal\Core\Entity\Query\Sql\Tables::addField is called with $field = "field_custom.reference__entity.field_number", it does its bits to figure out the tables to join, but early on it runs $column = $field_storage->getMainPropertyName(); which returns null, so when it gets down to $sql_column = $table_mapping->getFieldColumnName($field_storage, $column);, inside that method the column name is getting appended as null since there isn't a primary property.
$column_name = !in_array($property_name, $this->getReservedColumns()) ? $field_name . '_' . $property_name : $property_name;
So I see where its breaking and technically why, but not sure how to resolve it. Will attack it more tomorrow.
mrconnerton → created an issue.
mrconnerton → created an issue.
mrconnerton → changed the visibility of the branch 2816033-listener-registration to hidden.
mrconnerton → changed the visibility of the branch 4.0.x to hidden.
The original MR was created February 1st 2024 against 8.x-3.x. I tried updating that MR / rebasing for 4.0.x but as indicated, the original MR commit wasn't created fully from the previous patch #156.
I don't want to keep messing with an MR I can't fully edit so I've created a new branch on the issue fork to reroll the #156 patch to the latest 4.0.x.
I've attached the patch and a reroll diff from 156-186.
@dcam had some comments on his original MR that I'm sure are up for discussion by others.
At the end of the day, I was just looking this patch to fix a problem #156 solves on our site rerolled for 4.0.x.
MR is in mergeable state ready for review.
Adding a reroll_diff as requested.
I don't have the permissions to update the base target of the MR. Will wait for @dcam to do it else we can create a new MR.
Sorry, patch still isn't perfect. Need to remove '@entity_type.manager' from rules.event_subscriber
mrconnerton → changed the visibility of the branch 8.x-3.x to hidden.
Sorry missed a bit in the rebase. rerolled working here.
Rerolling patch for latest dev version of module.
drupal/core:^4.1
drupal/rules:dev-4.0.x#46815e3cca9fabd079f3b87e4dc5830e1aa28392
mherchel → credited mrconnerton → .
breidert → credited mrconnerton → .
I keep getting this randomly as well. Decent traffic site with lots of read / writes. Drupal 9.5.11. Memcache 8.x-2.5. Going to see if update to 8.x-2.7 helps.
I'm not sure if we want to note it somewhere, but I ran into an issue trying to run the addColumn from a custom drush script, not in the hook_update_n. The issue was the batch for content update was never being executed. All I had to do was add drush_backend_batch_process(); after the addColumn method to ensure the batch update of data was executed.
Created a MR for the basic update. Will continue testing locally, but initial errors have gone away and json:api results are returning properly now.
mrconnerton → created an issue.
Tested MR locally and all three conditions work. I didn't remove the LIKE operations as I didn't want to break whatever existing folk might have going. Not sure how it could work however since there is no way to wrap your value (via api) with db_like. I presume that is why CONTAINS, STARTS_WITH, AND ENDS_WITH exists in the first place.
mrconnerton → created an issue.
In addition to Child forms can be opened using a dialog or dedicated page it would be great if Child forms can be opened inline similar to inline_entity_form
Awesome, this is exactly the kind of feedback I was looking for and appreciate the quick research. Beanstalkd was always so easy to use and setup to offload the queue from the db, that part of me is still wondering is it worth the effort to take a stab at an updated version with pheanstalk v5. I guess I will have to take a look at the level of effort for RabbitMQ or Kafka as well.
mrconnerton → created an issue.
mrconnerton → created an issue.