I'm not sure if this problem has been dealt with, or if it is meant to function like this.

I've been programmatically adding filters via the $view->filter, before I build a view.
I've discovered that when I do:

$view->filter[] = array(
'tablename' => 'node',
'field' => 'nid',
'operator' => 'OR',
'value' => array(1,2,3,4)
);

I get SQL errors, where the tablename does not show up. I found that in views_query.inc, line 83 which has the following code:

    if (!$filterinfo['field']) {
      $fieldbits = explode('.', $filter['field']);
      $filterinfo['field'] = $fieldbits[1];
    }

That I can solve this problem by changing it to:

    if (!$filterinfo['field']) {
      $fieldbits = explode('.', $filter['field']);
      if (isset($filter['table']))
        $filterinfo['table'] = $filter['table'];
      $filterinfo['field'] = $fieldbits[1];
    }

I'm not sure if this is a bug, or is something more deliberate, to stop people from screwing around with programmatic filters, but I'd like to register the change if possible. I know it would be helpful to have the ability to filter by a list of nodes (for instance, when doing node_relativity queries). Making this functional would be extremely helpful.

CommentFileSizeAuthor
#6 views_query.inc-missing_table_in_query.patch464 bytessmk-ka

Comments

yched’s picture

yched commented

Off the top of my head, I think you need to call 

views_load_cache();
views_sanitize_view($view);

(or something like that) after adding your filters / fields / whatever, in order to make them ready for use.

rhys’s picture

rhys commented

This is what I wanted to call:

      $view = views_get_view( $view_name );
      if ($view) {
        $view->is_cacheable = false;
        // Create a filter for view 
        $view->filter = array(array(
          'tablename' => 'node',
          'field' => 'nid',
          'operator' => 'OR',
          'options' => '',
          'value' => $nid
          ));
        $view->url = "node/$node->nid";
        views_sanitize_view($view);
        $view_output = views_build_view('block', $view, array(), false, $view->nodes_per_block );
        $output .= $view_output;
      }

However, the problem arises, which is why I'm proposing this code change, is that the table name is ignored by _views_view_build_filters, when processing user defined filters.

Currently, the patch that is within the code I originally posted, solves this for me.
I was letting people know, IF this is the right thing to do.

ff1’s picture

ff1 commented

A similar problem was posted here: http://drupal.org/node/149881.

Does anyone know if this is a reliable fix for this problem?

I'm using Drupal 5.2 with Views 1.6 and am getting the same problem. I don't like to modify the code if I can help it, but if this is a real problem and if the fix works, then I'll try it.

ff1’s picture

ff1 commented
Version: 5.x-1.6-beta5 » 5.x-1.6

Changed version.

ff1’s picture

ff1 commented

I tried changing the code in views_query.inc as described above, but it did not work. I had a closer look at the code and the following worked for me:

<?php
  if (!$filterinfo['field']) {
    $fieldbits = explode('.', $filter['field']);
    // Next if statement added on 02/10/2007 by Ian Eldred
    // Fixes missing table name in filters added by code.
    if (isset($filter['table'])) {
      $filterinfo['table'] = $filter['table'];
    }
    else {
      $filterinfo['table'] = $fieldbits[0];
    }
    $filterinfo['field'] = $fieldbits[1];
  }
?>

I'm not really sure why this problem occurs. I suspect that prior to the code above being executed, the table and field values are combined such that the field value becomes 'table.field'. This field value is then exploded into $fieldbits and only the second array element is used.

I don't really understand the logic behind this, but the only time if fails to work is when the view is created programmatically, so I'll just accept it for now.

If anyone with some knowledge of the views module code can shed some light on this, that would be great.

Ian

smk-ka’s picture

smk-ka commented
Status: Active » Needs review
StatusFileSize
new views_query.inc-missing_table_in_query.patch464 bytes

A properly sanitized view should already have any filter fields expanded to 'table.field' syntax, as #5 correctly stated. Therefore, it should be enough to assign the missing table name

$filterinfo['table'] = $fieldbits[0];

to fix this issue.

esmerel’s picture

esmerel commented
Status: Needs review » Closed (won't fix)

At this time, only security fixes will be made to the 5.x version of Views.