| Project: | Flag |
| Version: | 7.x-2.x-dev |
| Component: | Views integration |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
| Issue tags: | Perfomance |
Issue Summary
There's a certain performance issue with the "Ops" field (in Views). I was aware of this from the start, but didn't bother to bring this up.
If you look in 'flag_handler_field_ops.inc' you'll see that its query() method adds a JOIN to the query. The reason is explained in the "Find out if the content is flagged [...]" comment.
And since there's already the main JOIN, we end up with *two* JOINs when the "Ops" field is shown in a view.
The comment I mentioned should be more explicit:
The reason for this extra JOIN is for cases when the flag relationship is added with a "user scope" of "Any user". In this case the "Ops" field handler can't know, just by examining the available columns, whether the item is flagged by the currect user. So it effectively does an extra JOIN with a "user scope" of "Current user".
It's easy to rid of this extra JOIN. This should only be done when the "user scope" of the relationship is "Current user" (and this probably happens in 90% of the cases when we also show the "Ops" field). The query() method should see if its relationship has its 'user_scope' option set to 'current'. If it does, it should skip adding a JOIN and instead have the two aliases ('is_flagged' and 'content_id') point to the columns of the current table.
Comments
#1
A different issue:
It's possible to add yet another performance enhancement to this "Ops" field:
In flag_handler_field_ops::pre_render() we're doing a query to find out which items are flaggable. We can add an "Assume all items are flaggable" checkbox to the Ops configuration form. This will allow the admin to skip this query.
But this is a minor (negligible, probably) preformance issue because this query is a simple one which doesn't affect the [potentially complex] main one.
#2
Moving
#3
A related support request: #728556: Flag_content table joined 2 times.
#4
#5
Marked #1162578: Slow view caused by joining to flag_content twice as a duplicate.
#6
Subscribing
#7
Updating title for clarity.
#8
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.
#9
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.
#10
Unless I am doing something wrong I'm not able to apply this patch. Error: Patch cannot be applied to selected content.