SQLSTATE[42S22]: Column not found: 1054 Unknown column *_target_id_int in on clause

Very same issue here.

I'm also seeing this on a few installs

AFAICT, the table is created with the whatever_target_id_int column after you submit the form where you choose the field type and enter its name. Then, when you submit the next form (where you choose the referenced types and the cardinality), a schema change results in the table being dropped and then created again, this time without the whatever_target_id_int column. This is using version 4.x-dev of the module on D10.

I'm seeing these errors on all my Drupal 10.1 updates

I also tried the Sandbox Module and receive the errors on a fresh install with both 3 & 4 versions.

to reproduce add sandbox with D10.1 & Dynamic Entity Reference
Activate media Module
add ref Field to Article type content type allowing Article and media image
save field

the error is there on both versions of the module for Drupal 10

I wonder if this is because of the move to READ_COMMITTED isolation level in Drupal 10.1 not recognizing Views (not Drupal views, DB Views)

The problem is with Drupal views: the module code expects those Drupal views to have access to the whatever_target_id_int field.

If I create a field and then add a whatever_target_id_int column to the table manually, I can create a Drupal view without issue.

I *could* create a patch to add that column, but it'd be better for a maintainer to weigh in about this.

So the module does some gymnastics to support config and content entities in a single field.

If you have both, we set the target ID as a string, but then use a DB trigger to keep an INT version in sync.

And then views does some dancing around that.

Can you share what your views data looks like for this error as well as your field definition?

Something like

drush php-eval "var_export(\Drupal::service('views.views_data')->get('YOUR TABLE NAME HERE'))";

Before my last comment I created a field 'test' on Article nodes. I set the field to accept content, terms, and users. Then, because it didn't have the column, I ran this in the db: alter table node__field_test add column field_test_target_id_int int not null default 0; and likewise with node_revision__field_test.

I then created a simple Drupal view to show Article nodes and added the 'test' field as one of the fields to show. That worked as expected. If I hadn't manually changed the db, I would have got the error in the first post here.

Note also that any triggers weren't created, or they were created but got wiped out when node__field_test was dropped and then recreated.

Due to all the "gymnastics" the module goes through, it'd be best if someone who's more familiar with it would weigh in. I'm also unsure on what is the expected setup: should it even have the field_test_target_id_int column? Was that being phased out but the Drupal views code just wasn't updated yet? Why did this stop working?

If no maintainers are available then I guess I could look into the module later on.

'if no maintainers are available' - this is my fourth comment on the issue so not sure what you're expecting there.

I'll see if I can reproduce it.

Confirmed this behaviour

It also looks like the events don't fire on update either.

Re the maintainers bit, I looked the first time not the second, so my bad. Let me know if you need help testing anything.

Moving to 4.x

Wondering if this is all that's needed.

In my testing, the column is added on create, but then the update event fires and core drops our column.

I tested the change using a field 'newtest'. The tables node__field_newtest and node_revision__field_newtest had field_newtest_target_id_int columns after the first screen and after the last. I was able to reference a user and a node from that field. I created a Drupal view as I described before and there aren't any warnings. It seems to work now.

The last submitted patch, 19: 3056416.patch, failed testing. View results →

I suspected that 4.x HEAD was failing because of this bug but if #19 is fixing the bug here then we need to investigate the HEAD fails separately but meanwhile let's add test for this bug.

HEAD is green now and so is the patch. Let's add some tests.

Here's a test

The last submitted patch, 24: 3056416-fail.patch, failed testing. View results →

The last submitted patch, 24: 3056416-pass.patch, failed testing. View results →

Hmm these pass/fail locally for me on 11.x - thoughts @jibran?

Sorry, I messed up the version check in one of the test fix but it is fixed now.

Committed and pushed to 4.x. Thanks!

Automatically closed - issue fixed for 2 weeks with no activity.