Pollfield database queries are run more than 15000 per node view

What CCK version are you using?

Pollfield is tested for latest recommended CCK version. From your queries I see that problem can be that pollfield is not compatible with new CCK.

I ran into this problem also. I made some tests on a 1.12-beta1 / drupal 6.17 installation and it looks like the translation aggregation is causing the extra sql queries.

Line 154
$tnid=db_result(db_query("SELECT tnid FROM {node} WHERE nid = %d",$node->nid));
This query results 0 if the node has not been translated at all.

Line 155
$t_nodes_results=db_query("SELECT nid FROM {node} WHERE tnid = %d",$tnid);
If tnid is 0, this query selects all nodes which haven't been translated, which might be all nodes in the system.

I guess I should try and provide a patch to help fixing this? This is my fist post to drupal.org so I'm not sure how to do that exactly so for now I'm just going to share this info.

Thanks for information. Everything you can provide as test or bug report is welcome. I will check this issue and provide fix as soon as possible.

@#4

http://drupal.org/patch/create

In case you haven't found it yet. Appreciate your efforts (and those of the maintainers of course).

Patch attached.

There are so many coding standard errors in this module, its quite incredible.

I did a little testing. The patch seems to work fine on 6.x-1.x-dev.

Thanks!

The patch makes sense and the changes are working well for me as well. Great job!

However. While I do agree with Steven on the coding standards I'd prefer to keep those kind of changes separate from this bug fix. I rolled a patch of my own for that reason, to make it easier to spot what changes were actually made.

My patch introduces nothing juhog and Steven haven't already made, so I'm taking the liberty to move this to RTBC.

subscribe

Mario?

Hi guys!
I was very,very busy last few months. I see there is lots of new activities and that is great. I will try to gather all patches you created and make new release.

Mario

I seem to be having the same issues (I think) as others, and will try to apply the patch today to see if that helps.

Thank you,

Chris

When a site has a large number of nodes, saving a poll (and likely displaying it) will take an extremely long time. One reason this seems to be the case is that there are the two queries which are executed:

 	$tnid = db_result(db_query("SELECT tnid FROM {node} WHERE nid=%d",$node->nid));
	$t_nodes_results=db_query("SELECT nid FROM {node} WHERE tnid = %d",$tnid);

The problem is that in some cases, when there are no translations, this can return 1000s of rows, and so the loop takes a long time, and will likely time out. It appears that in some cases within the module, there is a conditional around this statement to check for translations in the form of:

 	$tnid = db_result(db_query("SELECT tnid FROM {node} WHERE nid=%d",$node->nid));
	if ($tnid==0){//there is no translation
	  $t_nodes_results=db_query("SELECT nid FROM {node} WHERE nid = %d",$node->nid);
	}else{//there is translation
	  $t_nodes_results=db_query("SELECT nid FROM {node} WHERE tnid = %d",$tnid);
	}

Is there a reason that this can not be applied everywhere?

see patch... I haven't tested all cases, but i can now at least save (and view the poll).

Hi socki!

Did you see the patch above (Steven's original and my cleanup)? The patches addresses the same problem. However yours will always populate the $t_nodes_results, with only the $node if there are no translations. Later down the code it will iterate the $t_nodes_results result set but skip all results that are equal to $node. In effect, nothing is achieved but the loss of a couple of CPU cycles.

Let me know if you disagree, or else I feel we should still consider #9 RTBC and hope Mario commits it soon.

Hey... I saw that, and i like the idea of not even doing the query is its not necessary... I had seen elsewhere in the module that there was the if/else so i just continued with that. I'll try the patch above and see that it works for my use cases. The one question i had about the patch above is that appears that it only addresses a single instance... of the two queries when there are actually three such instances. It would seem that these other cases would also hang for a long period of time and should have the same treatment... unless that causes problems.

Basically something along these lines... Which will apply the same patch (from #9) but to the other two theme functions which have the same problem.. i haven't run into the issue of those two being called, but for the sake of completeness i guess we should make it consistent.

Looking forward to a new dev version, Mario :)

tnx for this patch!

Is this patch included in beta13?

i compared the code, and it does look like it is committed.

Mario could you set the issues that are fixed and commited to fixed? Thanks, can't wait to use this module, but it would like to know first what is fixed.

Yes, this issue is fixed several user tested it and it reported to me that is fixed.
I also fixed issue http://drupal.org/node/1031964.
For now that is what is on beta13

Soon as possible I will published on module page what is done and what you need to be aware of.
Thanks everybody for your contribution. My time was very limited last year and I am doing my best to keep this module. Your help is very valuable for module.

Greetings to all drupalists, Mario.

;)