Well - on friday my view was working. Today it is not.

I see:

user warning: Unknown table 'term_node_6' in field list query: SELECT DISTINCT(node.nid), node.title AS node_title, node.changed AS node_changed, node_data_field_id.field_id_value AS node_data_field_id_field_id_value, node_data_field_besetning_0.field_besetning_0_value AS node_data_field_besetning_0_field_besetning_0_value, node_data_field_soloister.field_soloister_value AS node_data_field_soloister_field_soloister_value, node_data_field_antall_original.field_antall_original_value AS node_data_field_antall_original_field_antall_original_value, node_data_field_antall_kopi.field_antall_kopi_value AS node_data_field_antall_kopi_field_antall_kopi_value, node_data_field_antall_instrumentalnoter.field_antall_instrumentalnoter_value AS node_data_field_antall_instrumentalnoter_field_antall_instrumentalnoter_value, term_node_6.name AS term_node_6_name, term_node_7.name AS term_node_7_name, term_node_8.name AS term_node_8_name, term_node_9.name AS term_node_9_name, term_node_10.name AS term_node_10_name FROM node node LE in /opt/drupal-4.7.3/includes/database.mysql.inc on line 120.

In the views admin I see in the fields list that the taxonomy columns are there - but that the "Name" column is blank. Trying to add a taxonomy term does not let me select what taxonomy or term.

I do have taxonomy access installed - but - I can view the categorized nodes directly just fine.

I need a hand working out what areas to investigate into - is it a damaged DB? (Categories look OK in category admin and on the nodes) - do I have an access prob? etc etc.

Comments

chrissearle’s picture

chrissearle commented

Oh - and BTW - I know the first question is "what did you change between then and now?" :)

I did remove the flexinode module from disk and the database - but it was uninstalled weeks ago in the modules list.

I seriously can't think of anything else I touched (although obviously something has happened). So - a good start - what _should_ that SQL look like?

If the table term_node_6 isn't correct - what should it be?

merlinofchaos’s picture

merlinofchaos commented

term_node_6 is a table alias. What it really means is term_node for the vocabulary with a 'vid' of 6. What that means is that either that VID was removed or for some reason Views cannot see it.

The first thing to do is to dump your cache and force Views to rebuild its table data, and see if the problem changes.

If it does not, the second thing to do is see if you have a vocabulary with a vid of 6. If you do not, then you will need to remove the blank field/filter from your View to fix the problem. If you do, I'm a little less sure what to do after that, since that means the problem is that you HAVE the vocabulary but Views can't see it. I can see where it's plausible that taxonomy_access might be an issue there.

chrissearle’s picture

chrissearle commented

OK - I should have tried that first - dumping the cache brought it all back. Thanks :)

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Fixed

Interesting. I'm still a little concerned; whatever caused it to disappear in the first place may cause it to disappear again if there are circumstances where the views cache is being rebuilt and it can't see that taxonomy id. Or maybe there was some fluke somewhere. This is something to keep an eye on, but unless you can figure out how to reproduce it there isn't a lot to be done about it. Keep an eye on it and reopen the issue if it happens again.

chrissearle’s picture

chrissearle commented

Leaving as fixed (since it is) - but I thought I'd just give a little more info - just in case it was useful.

When this happened, as well as the display of the view problem - I found that in the edit view dialog - the dropdown "Add field" - had the

Taxonomy: Terms for xxx

for one vocabulary - the only one that isn't used in a view.

The other 7 vocabs (5 in one view and 2 in another) were completely missing.

In the list of fields applied to the view where it should have said:

Taxonomy: Terms for xxx

it was blank.

The label was present.

The string:

This will display all taxonomy terms associated with the node that are members of xxx. Note that this causes one extra query per row displayed, and might have a minor performance impact.

was missing.

This issue was present in both the view with 5 vocabs and the one with 2.

Anyhow - thanks for your help - and I'll keep an eye on the situation :)

chrissearle’s picture

chrissearle commented
Status: Fixed » Active

Definitely some caching issue here.

The error has changed:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AND '') AND (. '') AND (. '') AND (. '') AND (. '') ORDER B query: SELECT DISTINCT(node.nid), node.title AS node_title, node.changed AS node_changed, node_data_field_id.field_id_value AS node_data_field_id_field_id_value, node_data_field_besetning_0.field_besetning_0_value AS node_data_field_besetning_0_field_besetning_0_value, node_data_field_soloister.field_soloister_value AS node_data_field_soloister_field_soloister_value, node_data_field_antall_original.field_antall_original_value AS node_data_field_antall_original_field_antall_original_value, node_data_field_antall_kopi.field_antall_kopi_value AS node_data_field_antall_kopi_field_antall_kopi_value, node_data_field_antall_instrumentalnoter.field_antall_instrumentalnoter_value AS node_data_field_antall_instrumentalnoter_field_antall_instrumentalnoter_value, term_n i /opt/drupal-4.7.3/includes/database.mysql.inc på linje 120

clearing the cache solved it yet again. Nothing has been changed in layout or structure - a couple of new posts were added - that's about it (and the new posts were not in this view - which is filtered on node type)

merlinofchaos’s picture

merlinofchaos commented

My best guess is that you've got some kind of access control restricting access to those vocabularies. Whenever views' cache needs to be regenerated, it's done as the user who happened to be logged in when this is needed, and my guess is that probably the vocabularies aren't 'visible' to that user for whatever reason. Do you use taxonomy access?

chrissearle’s picture

chrissearle commented

Yes - TA is in use. I think your guess almost has to be correct - if no user is logged in then the refresh will happen as anon? Anonymous does not have access to any terms in these vocabs.

Does this happen when a user clicks or via cron? I could perhaps script the cron cronjob to login first.

Is there any way to force a particular user for this?

Or - can caching be turned off just for views?

merlinofchaos’s picture

merlinofchaos commented

Are you using freetagging? Any time taxonomy terms or vocabulary is updated, views has to recalculate its data.

chrissearle’s picture

chrissearle commented

No - no freetagging. The vocabularies are fairly static. They will be updated - but then the user that is updating them has access.

chrissearle’s picture

chrissearle commented

If I knew what the triggers for updating the cache for views was - I could keep an eye on them. Am I basically looking for what happens to cause a call to views_invalidate_cache() ?

merlinofchaos’s picture

merlinofchaos commented

Yes.

catch’s picture

catch
he/him
Primary language English
commented

I'm having the same issue and also have tac installed.

Occasionally when updating a view or creating a new one "taxonomy terms for xxx" won't show in filters (always the same fixed vocabulary with vid 22). I tried flushing the cache as suggested, but no luck with that.

If I go to just "taxonomy term" - the terms are there, it's only "taxonomy terms for" which disappears, and just that vocabulary.

I use free tagging but not for the one that's affected.

I noticed I had "create" off by default in tac, will try to keep track of any changes that affect it.

catch’s picture

catch
he/him
Primary language English
commented

quick question:

Is there a significant performance benefit for using "taxonomy terms for" instead of "taxonomy term" when filtering? That'd be a temporary workaround for this if it doesn't slow things down much.

merlinofchaos’s picture

merlinofchaos commented

There is no performance hit or benefit for using one over the other; the addition is a convenience to make the selection process simpler.

merlinofchaos’s picture

merlinofchaos commented
Title: Aargh - taxonomy problems » Taxonomy Access can cause Views Data to be lossy due to restrictions when a user without privileges triggers a views cache clear

changing title

merlinofchaos’s picture

merlinofchaos commented

Bumping cause I do have to fix this.

crbassett’s picture

crbassett commented

I too am having problems with this, using TAC. I noticed you "bumped" this because you want to fix it. Has there been any progress or more tips?

chrissearle’s picture

chrissearle commented

Just been thinking. I still see this - so I have a cron job running nightly that does a

TRUNCATE cache;

in that database.

But - it just struck me - I have caching disabled in the site config (since it should only be active for anon users and this site requires login for 99.9%).

So - what is being cached and why if caching is disabled?

merlinofchaos’s picture

merlinofchaos commented

What you have disabled is page caching. Many systems inside drupal still cache data they need; if they did not, site performance would be awful.

chrissearle’s picture

chrissearle commented

Fair enough :)

crbassett’s picture

crbassett commented

I am continually running into this problem. What should I do to make cron clear this cache. Could I have it do that every hour? Any more news about this error?

chrissearle’s picture

chrissearle commented

I have this in my crontab

0 * * * * mysql -u<user> -p<pass> -e "truncate cache" <dbname>

Which then runs on the 0th minute of every hour of every day ....

Note - this is a linux cron job - not the cron.php cron run for drupal.

crbassett’s picture

crbassett commented

Has anyone had this problem with the 5.x version? I am wondering if this problem will go away when we upgrade our site to Drupal 5.1.

chrissearle’s picture

chrissearle commented

I've not seen it under 5.1 - but - the only site I have that is 5.1 and that is using TAC doesn't use views much (the only view I currently have on that site is one that is available to anonymous.

crbassett’s picture

crbassett commented

On our website, the two types of content that have restricted access each appear on a separate view. I only get this problem with the content type that has multiple vocabularies associated with it. The other content type has one "default" taxonomy term, which exists for the sole purpose of restricting access to that type of content. Each content type has one view to display all the current nodes of that type.

So, the one with multiple vocabularies has issues, the other does not. However, in the one content type that has multiple vocabularies, only one is "set" to restrict access (it is a set of terms that every node will have, so I can be assured that every node will have restricted access).

I don't know how much that helps, but it is just further observation on this problem. I suppose it is only a matter of time before Drupal 6 comes out and we can ignore this issue since it seems to go with 4.7.x.

catch’s picture

catch
he/him
Primary language English
commented
Version: 4.7.x-1.x-dev » 5.x-1.x-dev
Category: support » bug

This looks like another case of the taxonomy tree being cached. I no longer use tac so doesn't affect me any more.

catch’s picture

catch
he/him
Primary language English
commented
Title: Taxonomy Access can cause Views Data to be lossy due to restrictions when a user without privileges triggers a views cache clear » Views caches entire taxonomy tree
Priority: Normal » Critical

OK, this is now the official issue for this, all others are duplicate of this baby.

http://drupal.org/node/137496 was duplicate.

catch’s picture

catch
he/him
Primary language English
commented

http://drupal.org/node/145713 was duplicate.
edit: and http://drupal.org/node/152163

merlinofchaos’s picture

merlinofchaos commented
Assigned: Unassigned » merlinofchaos

Marking this issue so I can find it later.

chrissearle’s picture

chrissearle commented

Followup about d5. The site I was having the issue on is now 5.6 and I have not seen a single instance of this issue since upgrading to the 5.x series. I don't know if I'm just lucky or it really is a 4.x problem - but I thought I better let you know (of course - having posted this I bet it starts again tomorrow :))

skassam’s picture

skassam commented

For the record, I would just like to report I am running 5.5 with the same exact error using views and TAC. I will likely use the fix by truncating the cache table in cron.

chrissearle’s picture

chrissearle commented

OK - then at least we know that it _does_ affect 5.5 definitively. I really do wonder why I stopped seeing it - but - I won't complain.

blackdog’s picture

blackdog commented

Could it somehow be possible to 'fake' the first user when rebuilding the cache, instead of using the currently available user?

Or, what other ways are there to restrict access in a good way?

blackdog’s picture

blackdog commented

I understand that the development of Views 2 has put this issue back, but are there any progress? Any ideas how to solve it?

In an other issue (http://drupal.org/node/121390) the point has come up to never cache the taxonomy tree (for other reasons). Could that help this issue, or are those issues not connected?

I'm happy to dive into it, but any pointers would help...

Thanks!

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Closed (duplicate)

There is now a patch to try in http://drupal.org/node/272289 -- let's mark this dup and link back.

deekayen’s picture

deekayen commented

I'm concerned about this issue disappearing. We have a disappearing view that disappears from both the dynamic and exported versions, but it doesn't have any use of TAC or taxonomy at all for that matter, but the site does use node privacy by role. Just focusing on taxonomy doesn't seem to me like it'll really solve whatever the core cause is, just one case of it.

Just like some others have reported, we haven't been able to figure out specifically how to reproduce it.