Description of the bug
I'm troubleshooting exceptions in various tests for a custom module, where the base table being returned from views_handler_field_field::get_base_table() is null. These are for views with relationships via entityreference, for "Content referencing content from ..." and the resulting pseudofield names are in the form reverse_{field_name}_{entity_type}.
The following section of code is returning null:
/**
* Set the base_table and base_table_alias.
*
* @return string
* The base table which is used in the current view "context".
*/
function get_base_table() {
if (!isset($this->base_table)) {
// This base_table is coming from the entity not the field.
$this->base_table = $this->view->base_table;
// If the current field is under a relationship you can't be sure that the
// base table of the view is the base table of the current field.
// For example a field from a node author on a node view does have users as base table.
if (!empty($this->options['relationship']) && $this->options['relationship'] != 'none') {
$relationships = $this->view->display_handler->get_option('relationships');
if (!empty($relationships[$this->options['relationship']])) {
$options = $relationships[$this->options['relationship']];
$data = views_fetch_data($options['table']);
$this->base_table = $data[$options['field']]['relationship']['base'];
}
}
}
return $this->base_table;
}
The docblock indicates that a string should be returned, so I am thinking that if no base_table string is returned in the last if section, we keep the base table value from the entity instead of returning null. Is that reasonable?
Description of the bug
I'm troubleshooting exceptions in various tests for a custom module, where the base table being returned from
views_handler_field_field::get_base_table()isnull. These are for views with relationships viaentityreference, for "Content referencing content from ..." and the resulting pseudofield names are in the formreverse_{field_name}_{entity_type}.The following section of code is returning null:
The docblock indicates that a string should be returned, so I am thinking that if no base_table string is returned in the last
ifsection, we keep the base table value from the entity instead of returning null. Is that reasonable?