view with union works only first time

+1

have been battling this same issue but was working for me on my Windows devel box but same result you show once moving to server..

then i realized what difference there was between devel (Windows) and server (Debian)

i have this code in a module i use for test:

  $_isWindows = (strToLower(substr(PHP_OS, 0, 3)) === 'win');
  if ($_isWindows) {
      db_query("DELETE FROM {cache}");
      db_query("DELETE FROM {cache_filter}");  
      db_query("DELETE FROM {cache_menu}"); 
      db_query("DELETE FROM {cache_page}");
  } 

which i copied over from 4.7 days because when doing devel i hate having things hanging around in cache and confusing my debug.

sure enough, when i comment out this code - and basically make Windows box same as linux - viwes union is now busted on Windows box as well.. so, it would seem that this issue has something to do with caching..???

continuing to llok

ok this is definitely cache related but i dont think union related. I have similar issues with fused views. What version of views module do you use. I think this issue started when i upgraded from 1.5 to 1.6.. trying to back rev now and test.

just gets more and more odd...

this is the only cache dump line i need to fix this

db_query("DELETE FROM {cache} WHERE cid = 'imagecache:presets'"); 

and i have it running in a menu hook (i.e. runs on every page)

so looks like a bug in imagecache.. go figure...

I'm noticing this as well. The union-view displays all of the data the first time, but on page refresh it goes blank.

Also, if I edit the view and then save it again, it shows up again.

Sorry--one more thing, this may be a separate issue, but it may be related to the cache/settings... when I try and create a new (non-Unioned) view, the UNION settings from the Union view that I created last are still set as defaults for this view...

working through this and a few things... the query in the cache_views table is wrong - i suspect perhaps the the query without doing the merge??? but never gets to do the merge since it sees a value in the table so it never runs any of the views_union query alter code.

I guess this would point to something doing the right query to start with but then stores wrong value in cache.. which is why it works first time but not after wards.

i just need to find code where the cache query is getting filled... getting close

well getting pretty late here but this is where i have got to:

- i think that the main view gets stored in cache table and since it is there it pulls it and never runs views_union_views_query_alter
- and that view on its own has no results without the 2 views that it is joining

so heres a question on usability of this module??? if i have view A and view B to get a union do i create C as union of A and B

OR

do i simply create A and set it to be union'ed with B??? originally i could have swore i had this working with 2nd method; but afterwards only got it working with 1st method.. but perhaps if 2nd is correct this would fix this issue???

anyway.. since i have A, B, and C.. and C returns nothing on its own and this is what gets stored in cache.. i get no results

i can also see that A and B are marked in views table as not being cacheable.. but C is cacheable... so, of course, when i set the C view to not be cacheable either.. my view works correctly and all is well

but this isnt likely the answer here??

yes, if i set C to not be cacheable (directly edit the view_view table) then my issues go away - however anytime i edit or just resubmit the view the tbale gets set back to allow it to cache. Would need to find out where in the code this is being set??

hmmm.. interesting.. i think the key here is to find in the union code where it sets whatever it sets to make view cacheable.. or more likely i would guess this inst touched (and i dont think it is since i went looking for it) in the union module.. just views module setting by default.. but likely in the pre_view (i think that was there) hook in the union module it needs to explicitly set that it cant be cacheable???

very cool.. thanks for adding this..

This is still occurring - see thread here: http://drupal.org/node/234081

The new problem is caused by php not correctly serializing and unserializing the query object in some cases (it happened with pager queries for me, but not regular ones) causing a php 'invalid class/object', You can see this by doing a print_r on the 'master_queryobj' once it has been retrieved from the cache.

Apparently this can occur is the class definition is no longer available (perhaps we need to include a views .inc file that isn't included when the view is cached). The simplest way around it, however is simply to cast the views object to an array, and then back to a generic stdclass object. This worked for me at least!

Actually, I can reproduce this on PHP 5.2.3 (Ubuntu Gutsy), but not on 5.2.4 (Ubuntu Hardy). With 5.2.4 the unserialized view is already a stdclass object (and so is accessible by the code). Can anyone else reproduce the serialization issue above?

I was able to reproduce the serialization issue with PHP 5.2.5 under MAMP, but your patch seems to have solved things, Grugnog2.