I used a text-field in the filter-declaration of a view. As soon as this text-field is attached to another contenttype, the view does not work any more (error and no output). If you save the view definition again (without making any modifications), everything is correct.

Error message:
user warning: Unknown column 'node_data_field_FIELDNAME.field_FIELDNAME_value' in 'where clause' query ....

FIELDNAME = the name of the text-field

Comments

merlinofchaos’s picture

merlinofchaos commented
Project: Views (for Drupal 7) » Content Construction Kit (CCK)
Version: 5.x-1.5 » 5.x-1.x-dev
Component: Miscellaneous » Views Integration

Sounds like CCK is changing the name of the field on us. That could be a problem.

If this isn't fixable, CCK fields may need to mark themselves not cacheable.

karens’s picture

karens commented

The fieldname isn't changing so I don't know what is going on here. Will have to investigate...

karens’s picture

karens commented

OK, I know what the problem is. The reason this happened is that when you change a field from a stand-alone to a shared field or vice versa, its table changes, which means the views code must be updated to reflect the new table. Maybe this will be fixed by yched's proposal for cleaning up views fields when CCK fields are altered or deleted, but we should be sure that fixes this use case.

karens’s picture

karens commented
Title: View filter destroyed » View fields need updating when field sharing is changed

Changing the description a bit so it doesn't get missed.

merlinofchaos’s picture

merlinofchaos commented

Argh. Ok, then this is another case of Views' Inappropriately Caching Queries. This really needs to be fixed so that the cache is more fluid. It's turning into a pain in the butt.

yched’s picture

yched commented
Status: Active » Closed (duplicate)

moving to the more recent but more general http://drupal.org/node/117362

yched’s picture

yched commented

BTW, Earl : I don't think there is a problem with Views inappropriately caching queries : CCK currently makes the choice not to use 'cacheable' = 'no' for its fields, so Views is behaving correctly on that account.

merlinofchaos’s picture

merlinofchaos commented

The problem is that there is no mechanism to flush a views' cached query. If it were stored in the regular cache it could flush that cache more readily.

yched’s picture

yched commented

Right. That is true.
Is this something you plan to have in a next release (which means we could ditch the cck issue for now), or is this Views 2 stuff ?

merlinofchaos’s picture

merlinofchaos commented

I haven't figured out where that fix is going to end up yet. It may be Views 2...but it doesn't have to be. It's an effort thing.

yched’s picture

yched commented
Status: Closed (duplicate) » Active

setting back as active and http://drupal.org/node/117362 as duplicate after all :-)

yched’s picture

yched commented

OK - does this mean you're expecting patches for this ?

merlinofchaos’s picture

merlinofchaos commented

I would accept patches but I am not expecting patches for it.

yched’s picture

yched commented

Let's get to it then :-)

BTW, this won't solve the issue on CCK field deletion, which occurs even if no query is cached. This would require removing the corresponding field / filter / arg / sort from the view instead of just regenerating the query.
I wonder if that's cool BTW, altering a view in the user's back ? Might be troublesome for args, have unexpected consequences on paths patterns...

merlinofchaos’s picture

merlinofchaos commented

It should be okay if you do it right.

yched’s picture

yched commented

views patch submitted at http://drupal.org/node/118069

yched’s picture

yched commented
Status: Active » Fixed

should be fixed with latest CCK 1.5 and Views 1.6 (even if Views 1.6 is still beta)

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)