Lots of errors when upgrading from 1.5

ARe you sure you used beta4? This error would happen with beta3 but *should* be fixed with beta4.

I too got the same when upgrading to beta4. The cache tables didn't exist before so all the warning errors flooded my screen.

Hi,

I'm also trying to get a hang of this module. i upgraded from the 1.6beta3 thinking that it would correct the errors I was getting but no luck.

It keeps asking for a table but I'm not good at messing with the files and I had no luck trying to create a table through myPHPAdmin as I don't know what fields it would want or need.

I've updated both sites each time I did an update and even when I didn't, just to see if the errors would go away. I've also cleared the cache on the browser.

Is there going to be another upgrade or do I need to create a table for the database as if I was creating a file?

Would someone please help me.

-Thanks so much in advance,
SB

My errors (on both my test & prod sites) are as follows:

* user warning: Table 'drpl10.cache_views' doesn't exist query: SELECT data, created, headers, expire FROM cache_views WHERE cid = 'views_urls' in /home/mysite/public_html/includes/database.mysql.inc on line 172.
* user warning: Table 'drpl10.cache_views' doesn't exist query: SELECT data, created, headers, expire FROM cache_views WHERE cid = 'views_default_views:en' in /home/mysite/public_html/includes/database.mysql.inc on line 172.
* user warning: Table 'drpl10.cache_views' doesn't exist query: SELECT data, created, headers, expire FROM cache_views WHERE cid = 'views_tables:en' in /home/mysite/public_html/includes/database.mysql.inc on line 172.
* user warning: Table 'drpl10.cache_content' doesn't exist query: SELECT data, created, headers, expire FROM cache_content WHERE cid = 'content_type_info' in /home/mysite/public_html/includes/database.mysql.inc on line 172.
* user warning: Table 'drpl10.cache_content' doesn't exist query: LOCK TABLES cache_content WRITE in /home/mysite/public_html/includes/database.mysql.inc on line 172.
* user warning: Table 'drpl10.cache_content' doesn't exist query: UPDATE cache_content SET data = 'a:4:{s:11:\"field types\";a:3:{s:13:\"nodereference\";a:3:{s:5:\"label\";s:14:\"Node Reference\";s:6:\"module\";s:13:\"nodereference\";s:10:\"formatters\";a:2:{s:7:\"default\";a:3:{s:5:\"label\";s:7:\"Default\";s:11:\"field types\";a:1:{i:0;s:13:\"nodereference\";}s:6:\"module\";s:13:\"nodereference\";}s:5:\"plain\";a:3:{s:5:\"label\";s:10:\"Plain text\";s:11:\"field types\";a:1:{i:0;s:13:\"nodereference\";}s:6:\"module\";s:13:\"nodereference\";}}}s:4:\"text\";a:3:{s:5:\"label\";s:4:\"Text\";s:6:\"module\";s:4:\"text\";s:10:\"formatters\";a:3:{s:7:\"default\";a:3:{s:5:\"label\";s:7:\"Default\";s:11:\" in /home/mysite/public_html/includes/database.mysql.inc on line 172.
* user warning: Table 'drpl10.cache_views' doesn't exist query: LOCK TABLES cache_views WRITE in /home/mysite/public_html/includes/database.mysql.inc on line 172.
* user warning: Table 'drpl10.cache_views' doesn't exist query: UPDATE cache_views SET data = 'a:4:{s:6:\"tables\";a:78:{s:4:\"book\";a:5:{s:4:\"name\";s:4:\"book\";s:8:\"provider\";s:8:\"internal\";s:4:\"join\";a:2:{s:4:\"left\";a:2:{s:5:\"table\";s:4:\"node\";s:5:\"field\";s:3:\"vid\";}s:5:\"right\";a:1:{s:5:\"field\";s:3:\"vid\";}}s:7:\"filters\";a:1:{s:6:\"parent\";a:4:{s:4:\"name\";s:17:\"Book: Parent Node\";s:4:\"list\";s:37:\"views_handler_filter_book_parent_zero\";s:8:\"operator\";s:28:\"views_handler_operator_andor\";s:4:\"help\";s:53:\"This allows you to filter books based on parent node.\";}}s:5:\"sorts\";a:1:{s:6:\"weight\";a:3:{s:4:\"name\";s:12:\"Book: Weight\";s:7:\"handler\";s:30:\" in /home/mysite/public_html/includes/database.mysql.inc on line 172.
* user warning: Table 'drpl10.cache_views' doesn't exist query: LOCK TABLES cache_views WRITE in /home/mysite/public_html/includes/database.mysql.inc on line 172.
* user warning: Table 'drpl10.cache_views' doesn't exist query: UPDATE cache_views SET data = 'a:19:{s:15:\"album_grid_view\";O:8:\"stdClass\":15:{s:4:\"name\";s:15:\"album_grid_view\";s:8:\"disabled\";b:0;s:4:\"page\";b:1;s:10:\"page_title\";s:10:\"Album grid\";s:11:\"description\";s:41:\"Provides a grid view of items in an album\";s:6:\"access\";a:0:{}s:13:\"view_args_php\";s:0:\"\";s:9:\"use_pager\";b:1;s:14:\"nodes_per_page\";i:15;s:4:\"sort\";a:2:{i:0;a:5:{s:9:\"tablename\";s:4:\"node\";s:5:\"field\";s:11:\"node.sticky\";s:9:\"sortorder\";s:4:\"DESC\";s:7:\"options\";s:0:\"\";s:2:\"id\";s:11:\"node.sticky\";}i:1;a:5:{s:9:\"tablename\";s:4:\"node\";s:5:\"field\";s:8:\"node.nid\";s:9:\"sortorde in /home/mysite/public_html/includes/database.mysql.inc on line 172.
* user warning: Table 'drpl10.cache_views' doesn't exist query: LOCK TABLES cache_views WRITE in /home/mysite/public_html/includes/database.mysql.inc on line 172.
* user warning: Table 'drpl10.cache_views' doesn't exist query: UPDATE cache_views SET data = 'a:1:{s:11:\"review_list\";s:17:\"node/$arg/reviews\";}', created = 1176766968, expire = 0, headers = '' WHERE cid = 'views_urls' in /home/bootleg/public_html/includes/database.mysql.inc on line 172.
* There are updates available for one or more of your modules. To ensure the security of your server, you should update immediately. See the update status page for more information

Here's what I get upgrading from 1.5 to 1.6-beta4:

* user warning: Table 'drupal5.cache_views' doesn't exist query: SELECT data, created, headers, expire FROM cache_views WHERE cid = 'views_tables:en' in /web/drupal-5.1/includes/database.mysql.inc on line 172.
* user warning: Table 'drupal5.cache_views' doesn't exist query: LOCK TABLES cache_views WRITE in /web/drupal-5.1/includes/database.mysql.inc on line 172.
* user warning: Table 'drupal5.cache_views' doesn't exist query: UPDATE cache_views SET data = 'a:4:{s:6:\"tables\";a:19:{s:12:\"image_attach\";a:4:{s:4:\"name\";s:12:\"image_attach\";s:4:\"join\";a:2:{s:4:\"left\";a:2:{s:5:\"table\";s:4:\"node\";s:5:\"field\";s:3:\"nid\";}s:5:\"right\";a:1:{s:5:\"field\";s:3:\"nid\";}}s:6:\"fields\";a:1:{s:3:\"iid\";a:4:{s:4:\"name\";s:27:\"Image Attach: Display Image\";s:7:\"handler\";a:3:{s:36:\"image_attach_views_handler_field_iid\";s:5:\"Image\";s:46:\"image_attach_views_handler_field_iid_link_node\";s:33:\"Image with link to attaching node\";s:47:\"image_attach_views_handler_field_iid_link_image\";s:33:\"Image with link to attached image\";}s:6:\"option\";a:2:{s:5:\"#type\";s:6:\"select\";s:8:\" in /web/drupal-5.1/includes/database.mysql.inc on line 172.

Here's what seemed to have worked:

The following queries were executed
views module
Update #12

* ALTER TABLE {view_view} ADD is_cacheable int(1)
* UPDATE {view_view} SET is_cacheable = 1 WHERE vid = 1
* UPDATE {view_view} SET is_cacheable = 0 WHERE vid = 2
* ALTER TABLE {view_view} DROP query
* ALTER TABLE {view_view} DROP countquery
* CREATE TABLE {cache_views} ( cid varchar(255) NOT NULL default '', data longblob, expire int NOT NULL default '0', created int NOT NULL default '0', headers text, PRIMARY KEY (cid), INDEX expire (expire) ) /*!40100 DEFAULT CHARACTER SET UTF8 */

Update #13

* DELETE FROM {cache_views}

Update #14

* DELETE FROM {cache_views}

Ditto, identical errors on update. Getting errors on editing views too:

user warning: Unknown column 'query' in 'field list' query: UPDATE tee2i_view_view SET vid = '1', changed = '1176813561', name = 'articles', access = '4, 1, 2, 6, 5, 3', description = 'Front page articles listing.', page = '1', url = 'articles', page_type = 'teaser', page_title = '', use_pager = '1', breadcrumb_no_home = '1', nodes_per_page = '2', page_header = '', page_header_format = '1', page_footer = '', page_footer_format = '1', page_empty = '', page_empty_format = '1', menu = '0', menu_tab = '0', menu_tab_default = '0', menu_tab_weight = '0', menu_title = '', block = '0', block_type = 'node', block_title = '', nodes_per_block = '0', block_more = '0', block_use_page_header = '0', block_header = '', block_header_format = '1', block_use_page_footer = '0', block_footer = '', block_footer_format = '1', block_use_page_empty = '0', block_empty = '', block_empty_format = '1', view_args_php = '', query = '', countquery = '' WHERE vid = '1' in /some_path/html/includes/database.mysqli.inc on line 151.

and update_status is incorrectly reporting the Views version for some reason...

Same issue here, and what's worse is I can't seem to roll back to 5.x-1.5 now. My first reaction to seeing the errors above was to try and remove 5.x-1.6-beta4 completely through Modules and then reinstall it, but that failed with similar errors to the above. I then removed it in Modules and deleted the tables, and reinstalled again but that also failed with the same errors. Now after trying to roll back to 5.x-1.5 I get:

    * user warning: Table 'drupal5.drupal_view_view' doesn't exist query: SELECT COUNT(*) FROM drupal_view_view in /var/www/includes/database.mysql.inc on line 172.
    * user warning: Table 'drupal5.drupal_view_view' doesn't exist query: SELECT vid, name, description, menu_title, page_title, block_title, url, page, menu, block FROM drupal_view_view ORDER BY name LIMIT 0, 25 in /var/www/includes/database.mysql.inc on line 172.
    * user warning: Table 'drupal5.drupal_view_view' doesn't exist query: SELECT name FROM drupal_view_view in /var/www/includes/database.mysql.inc on line 172.

(drupal_ = my table prefix)

The old version is still there and anyone is welcome to use it. The fact that it is called "beta" should alert you that it is not for the faint-of-heart. While none of us is happy about the problems, including, I am sure, Merlin, it is the risk of using beta software. That's why I always keep the known-working version handy if I upgrade to betas. It took me 15 seconds to revert.

IF YOU ARE EXPERIENCING THIS PROBLEM:

Manually create your cache_views table:

CREATE TABLE cache_views ( cid varchar(255) NOT NULL default '', data longblob, expire int NOT NULL default '0', created int NOT NULL default '0', headers text, PRIMARY KEY (cid), INDEX expire (expire) ) /*!40100 DEFAULT CHARACTER SET UTF8 */ ;

silurius: There's something additional going on with your setup. There is absolutely no way that this process could have removed your view_view table -- that just cannot have happened here. I have no explanation for what else might have happened, but I recommend you mentally retrace your steps, so to speak, and see what else may have happened to cause that.

Aren Cambre: The drupal.org release system doesn't really understand the difference between 'beta' and regular releases, so I don't have any ability to list one over the other; it is going to list the most recent release for the branch. All I can do is tell you that if a product has 'beta' in the name, it is a very wise idea to ensure you have backups prior to installing it. I called it beta for a reason.

> ...it is the risk of using beta software. That's why I always keep the known-working version handy if I upgrade to betas. It took me 15 seconds to revert.

Yup - and it would make sense to take a db dump too, ready for a quick roll back.

"There's something additional going on with your setup. There is absolutely no way that this process could have removed your view_view table -- that just cannot have happened here. I have no explanation for what else might have happened, but I recommend you mentally retrace your steps, so to speak, and see what else may have happened to cause that."

Well, the view_view table issue was, in hindsight, obviously self-inflicted. I only deleted it (by mistake) when I found myself hunting in the database for elements of this module that were left behind. As I said earlier, unchecking it from Modules and deleting the module in the file system, did not successfully uninstall the module. Something else was left behind and did not appreciate being rolled back, and in the end I ended up doing exactly as you just suggested (full db restore).

Back when I was in the mainframe business, one truism was always evident: Fast-followers had better be ready to debug the software. I downloaded 1.6 because I don't care; I don't use Views heavily, mostly as a helper module. If you have a lot invested in Views, don't download the latest version. Let someone else debug it for you, especially if it's called "beta." Quit complaining.

I had these problems when upgrading; And I've broken my site a number of times, and having a two click backup before venturing into beta makes me feel better. I just open the desktop shortcut to the site's backup script and a few seconds later I have all mysql tables in a zip file on the server. phpmybackuppro.net I'm sure there are others but this one seemed nice.

and to make a backup shortcut you choose schedule backup, click show script, then save the script to a new backup.php file and make shortcut to that.

I had a temporary fix by putting the clear cache php in a page but wanted to fix this once & for all. So I took another try at creating the table in phpMyAdmin & followed all the information to create. I left out the "40100 DEFAULT CHARACTER SET UTF8" because I didn't know where to put that. The table was created & the errors have disappeared.

Thanks again

Just wanted to share.
-SB

Will next release fix the table issue?

Will next release fix the table issue?

I sure hope so! =)

subscribing

I have been reading the entries in this report. I also tried to install this module in my site, but as I have started to learn, I only tried it with my test site before doing it on my production site. The number of errors I got when updating my 1.5 version to 1.6beta4 was several screenfulls.

I doubt that the procedure followed is adecuate. You should take into account that there is a module called update status that watches the updates and tells you that your site is not updated when some new official version is out. Official versions should be that, official ones, not test ones. For test ones, you have the dev branches. Otherwise I will keep having my update status telling me that my site is not updated when in fact there is a false official version which is in fact a development one.

Please, don't pervert the method and follow the standard procedures that everyone follows. DEV is for development versions, official is for stable ones.

You should take into account that there is a module called update status
Merlinofchaos should now, he coded that module :-)

While i do get the real annoyance of upgrading to a new version of a module to find out it's not stable, I think people should go easy on this. Views is a big, central and complex module, receiving lots of feature requests and feature patches. Earl (merlin) is maintaining this on his own, being one of the very few (if not the only one) that has the big picture about the module. He has been doing an awesome job actually taking a huge lot of requests into consideration instead of turning them down with a simple 'won't fix, no time', reviewing / fixing the patches or providing them himself (while giving support AND submitting high profile patches for drupal core), making Views one of the most evolving projects out there. Of course, this in turns adds to the complexity of the code and the implications of every new feature that gets in.

Earl was wise enough to tag the releases with -beta, that should be a self explanatory warning for people with production sites, while allowing for a wider testing of the 1.6 code.

It's quite natural that people inquire about when the release will get stable, but the 'how could this happen ?' parts could be left out IMO.

Ok, first, I wrote the update status module. I know how it works.

First, as I explained, update status doesn't understand -beta and the like. -dev isn't -beta.

I'm really DAMN sorry this isn't adequate for you assholes, but I'm sick of the whinining in this thread. I have explained the situation. It is clearly an oversight with update status. If you think it's a problem with Views, then here is your option:

Uninstall Views.

I'm serious. It is this kind of ASININE WHINING CRAP that makes me question why i spend so much of my time writing software for FREE. The next time you feel the need to bitch about what a shitty job I'm doing, I advise you to remember the price you pay for your free software.

Come on, guys, take it easy.

From your replies I suppose you are fed up by who knows what reason. In this state of anxiety, I would consider taking a rest.

Your work is really amazing (the update status module is marvelous), and you shouldn't take technical criticisms personally (I think my criticism was technical rather than anything else). I know that I get free soft and I can't ask for anything, and I can only thank those who spend part of their lives developing for free. But I also understand that those who develop free software do it because they want. No one is obliged to develop for free and no one is forced to consuem free soft, it's a matter of freedom. And in this context of freedom, people can express their opinions, and you can educately ignore them :)

In my case this version was no problem at all. I learnt the hard way the need to have a test site. My first install got screwed when installing category module. Since then, I always try modules first in the test site. And that's what I suggest everyone: install this beta version in your test sites and play with it.

In any case, coming back to the versions name aspect, and about this beta name thing, having beta soft distinction would be a nice thing inside drupal. Other modules would use this tag for sure, and I thing I recall some ecommerce version named as beta version too.

Farreres: the beta topic has come up in the update status queue, and will likely be addressed at some point in the next version. To be honest, it was plain oversight. We were so excited to even have the system available that it never really occurred to me (or anyone else involved in the project) to add any kind of special handling for stuff with the 'extra' field. This is partly because it's not at all defined by the release system itself; developers can put whatever they want there.

This means we need to take some additional steps for beta versions. And we'll get this done, but like everything, it won't be immediate.

Related error message in logs - Maybe this information will help debug...

I saw those same cache-related error messages when I was updating Views. Like this 'cache_views' doesn't exist query: UPDATE cache_views SET data =', etc

The site still seems to be functioning OK, but I also get an additional PHP/MYSQL error in the Log with almost every page hit. Does anyone else see this one in their Drupal Logs?

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 'ORDER BY DESC LIMIT 0, 5' at line 1 query: SELECT DISTINCT(node.nid), value, node.title AS node_title, node.changed AS node_changed FROM node node LEFT JOIN term_node term_node ON node.nid = term_node.nid LEFT JOIN term_data term_data ON term_node.tid = term_data.tid AND term_data.vid IN ('1','2') WHERE (term_node.tid IS NOT NULL) AND (term_data.tid IS NOT NULL) AND (node.status = '1') GROUP BY node.nid, ORDER BY DESC LIMIT 0, 5 in /[PATH TO MY SITE]/includes/database.mysql.inc on line 172.

This error stops if I turn off the main Views module. It looks like it occurs once on every page load where the Views module is called, EXCEPT the front page (the front page does use Views, but it's a custom front page created by Panels module).

This issue is essentially a documentation problem, particularly with the new update module. It gives you a really frightening looking bright red warning that you should update, but unfortunately, it's telling you to update to a beta in some cases... I just followed the instructions without thinking

Just want to add a big Thank You to Merlinofchaos, whose name we seem to see on half of the really useful modules that are essential for our Drupal site.

Not a Views module problem, but I think this message that appears when you run update.php could also be misleading people into applying the beta Views module. It's coming from the CCK module update process, apparently

CCK 1.5 is targetted to work with Views 1.6. For a better CCK / Views integration, it is advised you update your Views installation.

Our problems (see comment #28) seem to be fixed after:
1) Unpacking (tar) views 5.x.1.5 on top of 5.x.1.6-beta4
2) Restoring database from backup made just prior to updating Views and other modules

ran update.php after this (had a bunch of other module updates installed since the db backup)

I think I've finally go tthe update from 1.5 -> 1.6-beta problems fixed in -dev.