Views 2.7 creates SQL statements containing ambiguous GROUP BY references, which render it unusable for our site. Views 2.6 didn't do that.

We have a following view:

$view = new view;
$view->name = 'es_blogi_iso';
$view->description = '';
$view->tag = '';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('fields', array(
  'title' => array(
    'id' => 'title',
    'table' => 'node',
    'field' => 'title',
    'label' => '',
    'link_to_node' => TRUE,
  ),
  'uid' => array(
    'id' => 'uid',
    'table' => 'users',
    'field' => 'picture',
    'label' => '',
  ),
  'field_teaser_value' => array(
    'id' => 'field_teaser_value',
    'table' => 'node_data_field_teaser',
    'field' => 'field_teaser_value',
    'label' => '',
  ),
  'comment_count' => array(
    'id' => 'comment_count',
    'table' => 'node_comment_statistics',
    'field' => 'comment_count',
    'label' => '',
  ),
  'nid' => array(
    'id' => 'nid',
    'table' => 'node',
    'field' => 'nid',
    'label' => '',
  ),
  'name' => array(
    'label' => '',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'strip_tags' => 0,
      'html' => 0,
    ),
    'link_to_user' => 0,
    'overwrite_anonymous' => 0,
    'anonymous_text' => '',
    'exclude' => 0,
    'id' => 'name',
    'table' => 'users',
    'field' => 'name',
    'relationship' => 'none',
  ),
));
$handler->override_option('sorts', array(
  'created' => array(
    'id' => 'created',
    'table' => 'node',
    'field' => 'created',
    'order' => 'DESC',
    'granularity' => 'second',
  ),
));
$handler->override_option('filters', array(
  'tid' => array(
    'id' => 'tid',
    'table' => 'term_node',
    'field' => 'tid',
    'limit' => FALSE,
    'operator' => 'or',
    'type' => 'select',
    'value' => array(
      '0' => '8',
      '1' => '86',
      '2' => '10',
      '3' => '85',
    ),
    'exposed' => TRUE,
    'expose' => array(
      'identifier' => 'filter0',
      'label' => '',
      'operator' => '',
      'optional' => '0',
      'single' => '0',
    ),
  ),
  'status' => array(
    'id' => 'status',
    'table' => 'node',
    'field' => 'status',
    'value' => '1',
  ),
));
$handler->override_option('access', array(
  'type' => 'none',
  'role' => array(),
  'perm' => '',
));
$handler->override_option('cache', array(
  'type' => 'time',
  'results_lifespan' => '60',
  'output_lifespan' => '60',
));
$handler->override_option('title', 'Blogit');
$handler->override_option('header_format', '1');
$handler->override_option('footer_format', '1');
$handler->override_option('empty_format', '1');
$handler->override_option('items_per_page', '4');
$handler->override_option('use_more', '0');
$handler->override_option('use_more_text', 'lisää');
$handler->override_option('distinct', TRUE);
$handler->override_option('style_plugin', 'list');
$handler->override_option('style_options', array(
  'type' => 'ul',
));
$handler->override_option('row_options', array(
  'teaser' => FALSE,
  'links' => TRUE,
));
$handler = $view->new_display('block', 'Lohko', 'block_1');
$handler->override_option('block_description', '');
$handler->override_option('block_caching', -1);

In views 2.6, the view works, excecuting the following SQL statement:

SELECT DISTINCT(node.nid) AS nid,
   node.title AS node_title,
   users.picture AS users_picture,
   users.uid AS users_uid,
   users.name AS users_name,
   node_data_field_teaser.field_teaser_value AS node_data_field_teaser_field_teaser_value,
   node_data_field_teaser.field_teaser_format AS node_data_field_teaser_field_teaser_format,
   node.type AS node_type,
   node.vid AS node_vid,
   node_comment_statistics.comment_count AS node_comment_statistics_comment_count,
   node.created AS node_created
 FROM lanka_node node 
 INNER JOIN lanka_term_node term_node ON node.vid = term_node.vid
 INNER JOIN lanka_users users ON node.uid = users.uid
 LEFT JOIN lanka_content_type_juttu node_data_field_teaser ON node.vid = node_data_field_teaser.vid
 INNER JOIN lanka_node_comment_statistics node_comment_statistics ON node.nid = node_comment_statistics.nid
 WHERE (term_node.tid IN (8, 86, 10, 85)) AND (node.status <> 0)
   ORDER BY node_created DESC

In views 2.7, it creates the following erroneus statement, which includes an ambiguous “nid” GROUP BY reference:

SELECT DISTINCT(node.nid) AS nid,
   FIRST(node.title) AS node_title,
   FIRST(users.picture) AS users_picture,
   FIRST(users.uid) AS users_uid,
   FIRST(users.name) AS users_name,
   FIRST(node_data_field_teaser.field_teaser_value) AS node_data_field_teaser_field_teaser_value,
   FIRST(node_data_field_teaser.field_teaser_format) AS node_data_field_teaser_field_teaser_format,
   FIRST(node.type) AS node_type,
   FIRST(node.vid) AS node_vid,
   FIRST(node_comment_statistics.comment_count) AS node_comment_statistics_comment_count,
   FIRST(node.created) AS node_created
 FROM lanka_node node 
 INNER JOIN lanka_term_node term_node ON node.vid = term_node.vid
 INNER JOIN lanka_users users ON node.uid = users.uid
 LEFT JOIN lanka_content_type_juttu node_data_field_teaser ON node.vid = node_data_field_teaser.vid
 INNER JOIN lanka_node_comment_statistics node_comment_statistics ON node.nid = node_comment_statistics.nid
 WHERE (term_node.tid IN (8, 86, 10, 85)) AND (node.status <> 0)
 GROUP BY nid
  ORDER BY node_created DESC

We have many similar views; actually, half of all the views on our site broke under Views 2.7 due to similar errors. So, due to this bug, Views 2.7 is currently unusable for us.

Comments

plj’s picture

For clarification: the exact DB error is ERROR: column reference "nid" is ambiguous, and DB itself is PostgreSQL 8.3.

deekayen’s picture

Not sure if it's related or not, but on MySQL, my views that implement the distinct option are no longer filtering to a distinct nid, so I get duplicated rows in the result. I confirmed backgrading to 2.6 fixes it.

merlinofchaos’s picture

deekayen: Your problem is most likely fixed by the reversion of the workaround for the core distinct bug which is in -dev.

Not sure what to make of the original issue here.

merlinofchaos’s picture

Status: Active » Closed (duplicate)

This is almost certainly fixed by this: http://drupal.org/node/506818 -- please help test that?