Improve performance of the "Ops" field in Views

Moving

A related support request: #728556: Flag_content table joined 2 times.

Marked #1162578: Slow view caused by joining to flag_content twice as a duplicate.

Subscribing

Updating title for clarity.

I'm running into an issue with this not mentioned in the first post. If you have multiple flag ops fields on a view, the join happens multiple times. Normally this would never happen, but when you are using something like flag_form, you can actually "edit" a flag, as well as unflag/flag.

Attached patch fixes both my issue in #8, and bypasses the extra join when the user_scope option is set to "Current User" on the relationship.

Unless I am doing something wrong I'm not able to apply this patch. Error: Patch cannot be applied to selected content.

Patch applies, but I'm still getting two joins:

FROM 
{node} node
INNER JOIN {flag_content} flag_content_node ON node.nid = flag_content_node.content_id AND (flag_content_node.fid = '1' AND flag_content_node.uid = '1')
LEFT JOIN {users} users_flag_content ON flag_content_node.uid = users_flag_content.uid
LEFT JOIN {flag_content} flag_content ON node.nid = flag_content.content_id AND (flag_content.fid = '1' AND flag_content.uid = '1' AND flag_content.sid = '0')

+++ b/includes/flag_handler_field_ops.inc
@@ -74,27 +74,44 @@ class flag_handler_field_ops extends views_handler_field {
+    if (isset($relationship->options['user_scope']) && $relationship->options['user_scope'] == 'current') {
+      $table_alias = $relationship->alias;
+    }
+    // Otherwise, let's set up the alias, keeping it unique for this flag in
+    // case there are multiple flag relationships in a single view.
+    else {
+      $table_alias = 'flag_content_current_user_' . $flag->fid;
+    }
+    // Now that we have the table alias, let's see if it's already been joined
+    // to. If it hasn't, we'll set up a join.
+    if (!isset($this->query->table_queue[$table_alias])) {

This is the bit I'm suspicious of. Table aliases are tricksy things, and I don't think you can necessarily rely on them like that.

I've looked at this again with a clearer head, and now I get it :) The table alias gets a flag ID appended to it to guarantee uniqueness: 'flag_content_current_user_' . $flag->fid.

Patch looks good, and very well-documented too.

Here's a reroll for the DB changes in 3.x.

Issue #404150 by q0rban: Fixed unnecessary re-adding of table to views showing the 'ops' field with the 'current user' limit on the flag relationship.

The patch at #9 should be ok to apply to 2.x -- I don't think I changed anything like comments in my reroll.

If i install the latest dev do I need to change anything on my end? I have several views joined with flag and want to make sure I can simply upgrade to latest dev.

Thanks

I'm not sure what you mean exactly -- and at any rate, please could you post a support request rather than take an issue off-topic?

Maybe I wasn't clear enough, you said:

The patch at #9 should be ok to apply to 2.x -- I don't think I changed anything like comments in my reroll.

This leads me to believe I can upgrade to avoid the problems of this issue, but I do not want to upgrade if it will cause headaches with all my current views joined to flags.

Comment 14 tells you that this issue was fixed on 3.x, because of the way the status was changed.

However, I do not recommend switching production sites to 3.x yet. If you want this fix on 2.x please help test the patch.

Closed as outdated because Drupal 7 is EOL