New Release Brings cre_query_obj and comment_recommendation.module

Events happening in the community are now at Drupal community events on www.drupal.org.
Scott Reynolds's picture

Just released new version. Included in the this release is the new-fangled cre query object and comment_recommendation.module which recommends comments within the current node being viewed.

The object allows for joining on any table. Please remember to use {} and a name to identify your table.

For instance node_recommendation does this:

<?php
function node_recommendation_cre_query (&$query) {
  
$query->add_table("{node} n");
  
$query->add_column("n.title");
  
$query->add_where("n.nid=d.content_id1");
}
?>

Comments

Potential bug need help

Scott Reynolds's picture

From the start of this project I thought it would be desirable to recommend nodes of a given type (say 'story' or 'page' or 'blog') but because I abstracted the engine from the node table I let that feature go. Today I announce a solution and add that feature.

Now I am afraid of a collusion here (for which I need some more test to make sure) and i will explain. Might be easy to look at node_recommendation.module. I think my logic works...but i am a lil uneasy about it.

In hook_block() $op = view it does...

<?php
case 2: // call for the recommendations of a certain type
         
$n=variable_get('node_recommendation_type_n_value', 4);
         
variable_set('node_recommendation_type_query',1);
         
$content = node_recommendation_get_top_n($uid, $n);
           if (
$content == NULL) {
              return;
           }
         
$block['subject'] = t(variable_get('node_recommendation_type_title't('Recommended Nodes')));
         
$block['content'] = theme('item_list', $content );
      }
?>

and then when hook_cre_query() gets called...

<?php
function node_recommendation_cre_query (&$query) {
  
$query->add_table("{node} n");
  
$query->add_column("n.title");
  
$query->add_where("n.nid=d.content_id1");
  
   if ((
variable_get('node_recommendation_type_query',0)) == 1) {
     
//drupal_set_message('done');
     
$query->add_where("n.type = '".variable_get('node_recommendation_type_type','story')."'");
     
variable_set('node_recommendation_type_query',0);
   }
}
?>

it checks to see if that _type_query variable is set and if so, unsets it and then adds the WHERE clause to the pending query.

I am afraid that the other top_n call will beat the type query call to the hook and therefore, display the wrong nodes on the wrong block. My small test have not shown this, and unfortunetly, my two large datasets (movielens and participate.net) only have voting data on one node type (either story and blog respectivily ). Was wondering if

  • A.) anyone else thinks this bug exists and
  • B.) can show that it exists

Sorry I know this is gibberish but I am hoping that someone can confirm or deny my fears. (o and a side note, would this work with a cck created node type?)

Re: Potential bug need help

Scott Reynolds's picture

Ok, I'm a fool. Not so sure why I made things so complicated... fixed into a much nicer solution.

<?php
function cre_top($uid, $callback, $n = 10, $target_type = 'node', $tag = 'vote',$reference_type = NULL)
?>

Where callback is the function to call after the creation of the cre_object. That call back function should add the tables, columns and wheres as the module author sees fit. No bug anymore, promise

SoC 2006: Content Recommedation Engine

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: