Field schema foreign keys is always hard-coded to 'node' despite target type not set to node entity type

Temporary workaround: http://drupal.org/node/1340748#comment-5806046 (resave all entityreference fields after patch (click on edit, then on save without changing stuff)).

This not only messes up CTools relationships, but blocks developers of term related modules to target Entity reference fields cleanly (see #1981262: Entity reference support for Term Merge module).

This also causes Features containing entref fields to report as overridden all the time, with this sort of diff:

       'foreign keys' => array(
-        'node' => array(
+        'other_entity' => array(
           'columns' => array(
-            'target_id' => 'nid',
+            'target_id' => 'eid',
           ),
-          'table' => 'node',
+          'table' => 'other_entity',
         ),

Core bug, see #4.

So, then active.

Is this a problem in 8.x as well?

OK, so for the update function, something like this?

+++ b/entityreference.install
@@ -161,4 +161,39 @@ function entityreference_update_7002() {
+    $sql_field = field_read_field($field['field_name']);

You can say $field_name here, which is easier to read.

There's also a few tweak needed with comments - a full stop missing & a line that needs wrapping.

Other than that, looks fine.

I tried the patch on a site where Features kept reporting my entityreference field as overridden. The fields were correctly fixed in the DB, and the feature then required an update.

Thanks for the review Joachim, here are those changes.

Cool!

The latest patch is works well for an already running sites, but if you have a brand new site and you apply the patch before you enable the entityreference module then the problem with the 'foreign key' is still exists.

With respect to the last comment in #17 - see #8. The genesis of this problem was fixed in core, but if you have fields that were created before that was incorporated into your install, the update hook needs to run on them. So I think this is appropriately RTBC, if that was your only concern.

Can this at least be committed to -dev now?

I also wish this would get placed in the codebase. We are using:
Features 7.x-2.2
EntityReference7.x-1.1

and I am noticing this patch is not in the codebase...

I tried applying the patch, and I get index errors:

The patch applies cleanly to 7.x-1.x

I experience this on sites installed from scratch that use features. Since this is just an update function it doesn't fix the problem and I have to build my features twice so I don't have them overridden.

I develop sites installing the drupal profile every time so there's never update_hook involved.

I export the entity reference field with features and when I install the site again the feature is overriden. Once I re-export it is fine again.

Should I open a different issue for this?
What I get with:
drush features-diff myfeature

Component type: field_base
      'cardinality' => 1,
      'field_name' => 'field_course_category',
<     'foreign keys' => array(
<       'taxonomy_term_data' => array(
<         'columns' => array(
<           'target_id' => 'tid',
<         ),
<         'table' => 'taxonomy_term_data',
<       ),
<     ),
      'indexes' => array(
        'target_id' => array(

@rodrigoaguilera, I think temporary solution in this case is to update all entity reference fields with new foreign keys, recreated feature with those changes.
And for new fields use hook_field_update_field, so set proper foreign key.

/**
 * Implements hook_field_update_field().
 */
function hook_field_update_field($field) {
  // Load the base table configuration from the cache.
  $base_tables = variable_get('entityreference:base-tables', array());

  if ($field['type'] != 'entityreference') {
    // Not an entity reference field.
    return;
  }

  // Read in the field config
  $sql_field = field_read_field($field['field_name']);

  // Create a foreign key to the target entity type base type, if available.
  $entity_type = $sql_field['settings']['target_type'];
  if (isset($base_tables[$entity_type])) {
    list($base_table, $id_column) = $base_tables[$entity_type];
    $schema['foreign keys'][$base_table] = array(
      'table' => $base_table,
      'columns' => array('target_id' => $id_column),
    );
  }

  // Update foreign keys to actually contain the proper entity foreign keys if they differ.
  if ($sql_field['foreign keys'] != $schema['foreign keys']) {
    $sql_field['foreign keys'] = $schema['foreign keys'];
    field_update_field($sql_field);
  }
}

(Crossreferencing so this issue is visible on the fixed core issue as well.)

Cross-referencing with an issue in Features queue: https://www.drupal.org/node/2419479

Basically, starting Features 2.4 'foreign keys' are no longer exported as a part of field base.

I think this is still a problem when using features. Since foreign keys are removed from the field config, I believe they are empty when imported. I'm also using an install profile workflow and this patch wouldn't impact the site at all on a fresh installation.

hi
should apply this patch to entityreference module?

Rerolled for the most recent version of entity reference.

So the patch added a hook_update that fixes a problem that doesn't occur any more.

Given the age of this issue, does anyone still want this committed? If so, I'll test and commit it.

This probably needs to be entityreference_update_7101 now?

Will be useful and yes entityreference_update_7101().