Moving reviews to another node
Acert93 - January 30, 2007 - 05:42
| Project: | userreview |
| Version: | 4.7.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | gerd riesselmann |
| Status: | needs review |
Jump to:
Description
I am using Drupal 4.7. Currently we are using Flexinode for recipes, but with the Flexinode module officially being phased out we are seriously looking at moving to the Recipe module.
One of the hurdles we have is that we have about 200 reviews (userreview) of our recipes from dozens and dozens of users.
Any suggestions on how to approach this issue?
#1
The userreview module stores both the id and the type of the reviewed node. The according fields are "content_id" and "content_type" on the table "userreview".
So, if you are able to move to the recipe module while preserving the old node's ids - which should be possible -, all you have to do is to update the reviewed node's type:
UPDATE userreview SET content_type = 'recipe' WHERE content_type = '[OLD CONTENT TYPE]';If the node ids change, however, you must update them accordingly, too.
#2
What is the best way to create a new content node and have it use the same node ID as the content you want to replace? Will deleting the old node and immediately creating the new node give it the same node ID? (And if this approach works, what happens to reviews attached to a node when you delete the node? Do they sit in limbo and become attached to the new content created on the node ID?)
There are currently over 500 reviews (my guestimate was off) on about 250 recipes, so the process would probably have to be something where we migrated 10-20 recipes over per night. My manual MySQL abilities are pretty sparse, so I am wondering if updating the table is per-node or modulewide change?
#3
When loading, displaying, or editing a node, the node's type determines what modules and functions to invoke. Hence, if you are migrating from one node type to another, you can move the whole content to the new node type's table. It will become "visible" to Drupal only after you updated the field "type" in the table "node".
Userreviews of a given node will be attached unless the node's id changes. Altering the reviewed node's type like described in #2 can be done at the very end. The query given updates all reviews at once.
If your not that into SQL, best strategy is to write some custom temporary module that does the conversion. It can load all current content. Convert it to a recipe and store it afterwards. Pseudo code looks like this (Where current type has properties a, b, c and new type has properties x, y, and z):
<?phpfunction converting_module_convert() {
$sql = "Select nid from {node} where type='old_module_type'";
$query = db_query($sql);
while ($node = db_fetch_object($query)) {
$node = node_load($node->nid);
// convert
$node->x = $node->a;
$node->y = $node->b . "\n" . $node->c;
$node->z = $node->title;
$node->type = 'new _node_type';
// delete old properties
unset($node->a);
unset($node->b);
unset($node->c);
// We must insert in new table!
[new_node_type]_insert($node);
// and update node table
node_save($node);
}
}
?>
[new_node_type]_insert($node) will be recipe_insert($node) in your case. No guaranties this works, though.
#4
#5
Does not work. I am still diagnosing why though. Correct me if I'm wrong, but wouldn't it still be a node for content_type? After converting when I submit a review it creates an entry with the content_type=node and vote_tag=userreview:content_recipe.....it used to be node and userreview:flexinode-1.
So that seems easy enough. But when I change the entries to userreview:content_recipe they still don't show up. The weird thing is that if I login and submit a review, they will show up even if the vote_tag is set to userreview:flexinode-1. It's like there is a cache or something but I cannot find it. Also, if I submit a review they will all show up okay but it will say "Average vote based on 1 review" even though there are five.
Getting stuck in a rut, please enlighten me!
#6
Turns out there is some cache and such in the votingapi tables that I had completely missed. A few custom sql queries seemed to have taken care of everything.
Thanks.