Schema mismatch after upgrade D6 to D7

From which version to which version did you updated AND did you runned the update.php?

Did you really runned update.php? You didn't answered this question
As well as the version. It's required if this is really a bug.

Probably the easiest way is to just manually remove those columns. They're no longer used, though having them present isn't going to cause any problems, other than making schema module complain a bit.

But the problem still exist

Yeah, we do need to come up with a fix for this, it's just marked minor so it's not something we're going to rush to change.

Actually this isn't that minor as it seems to be, because many people will run into this.

Okay here are several update tests:

* 6.x-2.12 to 7.x-dev: No errors
* 6.x-2.x to 7.x-dev: No errors during update, schema report is fine.
* 6.x-3.x to 7.x-dev: no errors during update, but schema dismatch:

cache_views, cache_views_data:
  - headers: unexpected column in database

This problem doesn't seem to be related to the error reported above.

It would be really really great if someone with the problem come up and provide some data so we could go through the problem together.

I upgraded from 6.x-2.12 to 7.x-3.0-rc1 and I ended up with exactly the same schema mismatch. I could reproduce this when I upgraded the same site a second time.

I checked the schema version before and after the upgrade. According to the system table, it was 6009 before and 7001 after the upgrade, which is - IMHO - correct.

Let me know if I can do anything to further investigate this issue.

@dunix
Thanks for the real detailed report, from which version to which version, from which schema version to which schema version.
Easy but real effective. Assign to myself.

Some of the db_drop_table and db_drop_field calls haven't been updated to the new API. The attached patch should fix this.

Ups i recently fixed the install file for the $ret part.
Additional i checked for the already added human_name/core field. It would be cool if you could retest the upgrade.

dereine - nobody's commented in a couple of months; should we marked this fixed and hope for the best?

Should you add this to the install for 7?

  db_query("ALTER TABLE 'cache_views' DROP 'headers'");
  db_query("ALTER TABLE 'cache_views_data' DROP 'headers'");

@SangersDrupalDude

Could you please add a new issue for that?

The according drupal update function is system_update_7054()

This update (http://api.drupal.org/api/drupal/modules--system--system.install/functio...) only deals with core tables, not with contributed modules?

Right, but we could utilize or at least document it with that.

has changed in D7:

  db_drop_field('cache_views', 'headers');
  db_drop_field('cache_views_data', 'headers');

Nothing got committed so reopening this.

Working on a site that was about a year ago upgraded to D7, and when I check the db. for stray tables and other stuff came I across these old col. I found two more then noted in #24. Perhaps we should run a cleanup in views_update() to make sure they are gone once and for all? I know they don't do any harm but I think we should clean up so we don't run into surprises in the feature when we are migrating into newer versions etc.

db_drop_field('cache_views', 'headers');
db_drop_field('cache_views_data', 'headers');
db_drop_field('views_view', 'view_php');
db_drop_field('views_view'. ' is_cacheable');

I just updated another D6 site and got the same messages from schema about cache_views and cache_views_data

The other two look to be fixed in

/**
 * Remove the view_php and is_cacheable field
 */ 
function views_update_6010() {
  db_drop_field('views_view', 'view_php');
  db_drop_field('views_view', 'is_cacheable');
}  

rolled a patch of the hook_update_N.

I'm wondering whether we should do the same on Drupal 8?

Well, if we add it to D7 then that might catch folks. Aren't we *supposed* to upgrade to D7 prior to upgrading to D8?

Looking good to me.

Would be somehow cool, if we could add a small comment, to describe when this can happen.

dawehner: It would be cool if I knew why the situation happened for us, but I got to the site after it was upgraded from D6 => D7 and found it in the state where the schema was mis-matched.

Hard to reproduce, even harder to write something clever about how we got the site into this situation. Frankly I have no idea how to reproduce it. I cropped up on one or two sites I migrated to Drupal 7. Have no db. backups is the D6 site this came from....

#28: views_schema_mismatch-1154830-28.patch queued for re-testing.

I just updated from Drupal 6.34 to 7.34 and still see the mismatch. I applied the schema changes manually directly in the database...

We have this problem in several other modules, too.

What module or update has added this headers column in views? I cannot find it in any of the other affected modules schemas (l10n_packager, l10n_update) and also not in any other commit of these modules that it has been in the code in past. I'm confused how this column was created. Any idea?

Quick re-role and tested.

Over 4 years for such a simple patch. Unbelievable.

What module or update has added this headers column in views?

The question is answered in the code. system_update_7054(), which was introduced in 7.0-alpha6.

I considered using hook_update_dependencies() to link this update to system_update_7054(). But only 9 sites currently run older Drupal 7 versions. So I think it is safe assume that the system_update_7054() is already executed. A schema mismatch will not cause real problems.

+1 for RTBC

A schema mismatch will not cause real problems.

That depends on what. A wrong default can for sure cause serious issues if your code depends on a proper default value being set.

Thank you for the patch! Committed and pushed

Nice to see my first contribution getting committed after 3 years.This makes my day.