Create an entity reference field of type "Taxonomy vocabulary". Then create a taxonomy view, and try to add a relationship to the referencing entity that connects to that field - the label will be something like "A bridge to the Content entity that is referencing Taxonomy vocabulary via field_yourfieldname". The query that Views creates is broken, because Views does not define the necessary information about the taxonomy_vocabulary table - it has no "base" information, because you can't create a view on vocabularies.
The result is that it tries to join to taxonomy_vocabulary.
and you get an error like this
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '= field_data_field_yourfieldname.field_yourfieldname_target_id AND (field_data_field_yourfieldname' at line 2
The field name is missing because views_handler_relationship_entity_reverse->query() assumes that it can get it from ['table']['base']['field']
, which in this case is undefined. That also produces a PHP error:
Notice: Undefined index: base in views_handler_relationship_entity_reverse->query() (line 28 of /path/to/your/docroot/sites/all/modules/views/modules/field/views_handler_relationship_entity_reverse.inc).
I'm not sure where or how to fix this. The simplest thing is to patch Views to add base information for taxonomy_vocabulary but that's not a real solution. I don't know if there is a way to override or extend the base Views code so that Entity Reference can make it work.
Comment | File | Size | Author |
---|---|---|---|
#1 | entityreference-nonbase-relationships-2363287-1.patch | 4.22 KB | brad.bulger |
|
Comments
Comment #1
brad.bulger CreditAttribution: brad.bulger commentedThis patch works around the problem by extending the Views relationship handler class and duplicating its query() method with a slight alteration, allowing the definition to pass in the required target table left field name.
It's not a very satisfactory way of dealing with the problem, though, since it requires duplicating far too much internal Views code. I suppose that change could be introduced as a patch to Views itself, and then this fix could just be the changes required to make use of it. But maybe there is a better way altogether?
Comment #2
brad.bulger CreditAttribution: brad.bulger commentedwe've been running on this patch for 3 years so I guess it works well enough. still wonder if there is a better way.