Entity reference joins to the wrong base table in views.

1. +++ b/core/modules/entity_reference/entity_reference.views.inc
   @@ -39,19 +39,30 @@ function entity_reference_field_views_data(FieldStorageConfigInterface $field_st
   +      'help' => t('Relate each @entity with a @field_name set to the @label.', $args),
   

   I like the better help text.

2. +++ b/core/modules/entity_reference/src/Tests/Views/EntityReferenceRelationshipTest.php
   @@ -151,4 +151,79 @@ public function testRelationship() {
   +    // Create reference from entity_test_mul to entity_test.
   ...
   +    // Create reference from entity_test to entity_test_mul.
   

   Its good to have these 1 line summary documentation, this makes it really easy to scan the code.

@olli
This is not really what I meant.
You added new tests which ensure that specific views data is generated ... which is not a bad idea, but we still haven't a proper test that an entity reference query work as expected.

Needs work based upon my last feedback, sorry :)

I don't think we need this.

Are you sure about this? Other fields do a similar kind of join:

    $data[$table_alias]['table']['join'][$data_table] = array(
      'left_field' => $entity_type->getKey('id'),
      'field' => 'entity_id',
      'extra' => array(
        array('field' => 'deleted', 'value' => 0, 'numeric' => TRUE),
        array('left_field' => 'langcode', 'field' => 'langcode'),
      ),
    );

Thank you for working on it, great work!

@nuwe
Thank you for adding the tag.
This just fixes some bug on an API level, screenshots would not really add an value, IMHO :)
But sure we should post more screenshots of stopped debuggers.

Improve the existing code for sanity sake.

You could have tried to post an interdiff just containing the new test coverage ... :)
But sure +1 for renaming variables to be more sane and moving fields around in order to make it easier to read!

1. +++ b/core/modules/entity_reference/src/Tests/Views/EntityReferenceRelationshipTest.php
   @@ -51,103 +58,175 @@ protected function setUp() {
   +    foreach (array_keys($view->result) as $index) {
   ...
   +      $this->assertEqual($view->result[$index]->id, $this->entities[$index]->id());
   ...
   +    foreach (array_keys($view->result) as $index) {
   +      $this->assertEqual($view->result[$index]->id, 1);
   

   This is a bit odd ... why do we get the index but then just use it to access $view->result[$index}?
   Can't we just use foreach ($view->result as $row) and then use $row?

2. +++ b/core/modules/entity_reference/src/Tests/Views/EntityReferenceRelationshipTest.php
   @@ -51,103 +58,175 @@ protected function setUp() {
   +      // Also check that we have the correct result entity.
   +      $this->assertEqual($view->result[$index]->_entity->id(), $this->entities[$index]->id());
   +
   +      // Test the forward relationship.
   +      $this->assertEqual($view->result[$index]->entity_test_mul_property_data_entity_test__field_test_data_i, 1);
   +
   +      // Test that the correct relationship entity is on the row.
   +      $this->assertEqual($view->result[$index]->_relationship_entities['field_test_data']->id(), 1);
   +      $this->assertEqual($view->result[$index]->_relationship_entities['field_test_data']->bundle(), 'entity_test_mul');
   

   These tests are looking great! Exactly what I thought we should have test coverage for

3. +++ b/core/modules/entity_reference/src/Tests/Views/EntityReferenceRelationshipTest.php
   @@ -51,103 +58,175 @@ protected function setUp() {
   +    $view->destroy();
   

   You can skip the destroying if you reload the view anyway, just a tip.

Yeah, this is clearly a bug and its just luck that things work at the moment.