Under admin/build/schema/compare I get:

accesslog
o column sid:
declared: array('type' => 'varchar', 'length' => '64', 'not null' => TRUE, 'default' => '')
actual: array('type' => 'varchar', 'length' => '32', 'not null' => TRUE, 'default' => '')

node_type
o column name:
declared: array('type' => 'varchar', 'length' => '255', 'not null' => TRUE, 'default' => '')
actual: array('type' => 'varchar', 'length' => '255', 'not null' => TRUE)

But no information is given on how to fix this. With the next version could perhaps a link be returned to a page showing an example of the MySQL syntax that would be used to correct the problem?

BTW it's a 99% vanilla core 5.7 install, why would the mismatch even occur?

Files: 
CommentFileSizeAuthor
#1 table-accesslog-edit.png12.78 KBTallDavid

Comments

Priority:Minor» Normal
Issue tags:+default, +schema, +example, +phpMyAdmin
StatusFileSize
new12.78 KB

Hans,
to fix this type of schema miss-match, I'm using phpMyAdmin.

Make a backup of your database before you begin!

To take the first example, open your Drupal database with phpMyAdmin, navigate to the accesslog table, click the Structure tab, find the sid row and click the pencil icon to edit this row. You'll be presented with a table of fields that you can edit. Change the Length/Values field to the value indicated in the declared listing in the Schema module report (64 in this case) then click Save (see attached file for a screen shot). This procedure will update your Drupal database to match the declared schema for this item.

For the case (above) where you have a miss-match in the default values and the value is empty, it seems like the Schema module is "crying wolf". I haven't figured out a way to fix these reported default miss-matches using phpMyAdmin and they don't seem to cause any problems in the database so I've been ignoring them. If I'm mistaken, I'd appreciate someone explaining how to correct these errors using phpMyAdmin.

Lastly, I think that your suggestion on suggested MySQL syntax is a good one and should be entered as a formal feature request.

Hope this helps!
David

Status:Active» Fixed

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Version:5.x-1.1» 6.x-1.x-dev
Status:Closed (fixed)» Active

I just installed the module because it is required by other ones I need to use. I got these mismatches:

* search_dataset
          - column type - difference on: length
            declared: array('description' => t('TODO: please describe this field!'), 'type' => 'varchar', 'length' => 16, 'not null' => FALSE)
            actual: array('description' => t('TODO: please describe this field!'), 'type' => 'varchar', 'length' => '64', 'not null' => FALSE)
* search_index
          - column type - difference on: length
            declared: array('description' => t('TODO: please describe this field!'), 'type' => 'varchar', 'length' => 16, 'not null' => FALSE)
            actual: array('description' => t('TODO: please describe this field!'), 'type' => 'varchar', 'length' => '64', 'not null' => FALSE)
* search_node_links
          - column type - difference on: length
            declared: array('description' => t('TODO: please describe this field!'), 'type' => 'varchar', 'length' => 16, 'not null' => TRUE, 'default' => '')
            actual: array('description' => t('TODO: please describe this field!'), 'type' => 'varchar', 'length' => '64', 'not null' => TRUE, 'default' => '')

I know my way around either from phpmyadmin web interface or the cli, but my question doesn't have to do with how to correct the values but rather if I should.

I see the point in correcting the actual length values when the declared values are larger, but why should I do so if it is the other way 'round? Perhaps instead of correcting the values in the db I should correct them within the modules' configuration files (the core search module in this case). I don't want to tough core modules though.

So, should I report this as a core search.module issue or should I request a feature so that these cases (where length values are larger) should be ignored by the schema module's status report?

subscribing (lots of mismatches here too -- maybe its an April Fool's thing).

It's sort of an old issue, but it comes up at the top of my searches, and so to spare other people some pain, here's my suggestion: don't do anything with the mismatches. at least unless you've done careful checking first. Consider the comparison report instead to be an interested piece on information, but not necessarily something that is indicative of a problem.

In my installation, I have three types of mismatches:

1) Several tables show a mismatch because they have fields defined as an int type that include a length. MySQL supports this. At one point in time, Drupal documentation said to use this, though that has been changed recently as described in http://drupal.org/node/764064. That's all well and good, but it means that lots of previously-developed modules will include a length field for their int objects, and the schema report will complain about them when there is nothing you can do about it (file a bug against the offending module, I guess...)

2) Sometimes modules have bugs that cause the schema comparison report to erroneously report a mismatch -- the taxonomy_treemenu modules has just such a bug (http://drupal.org/node/857936). My inclination after getting this mismatch was to use myPhpAdmin as discussed above to remove that column from the table, but fortunately I didn't, which would have caused all sorts of issues with my site.

3) Tables that exist when they shouldn't, which are presumed to be left over after a module was disabled but not uninstalled. Many modules don't provide an uninstall hook, actually. So if you delete the tables by hand and then later want to re-enable the module, it won't work because the hook_install method (which is what creates the tables) won't get called because the module isn't being installed, only re-enabled.

The bottom line is to be very careful about changing the database and only do it if you really, really understand what is going on.

#6 puts the dilemma quite well. I'm operating a number of "old" Drupal sites that were started around 4.5 and 4.6, and a couple of sites started on D5; all those sites degrade continously with their age, in regard to performance, stability and legacy remainders like bloated variable tables, numerous tables from modules that not even exist in D5/D6 - and schema inconsistencies. In the past two years I have not seen a single Drupal site that went through at least one major core upgrade with a "clean" database schema.

A typical report from 'schema' module looks like this:

60 extra tables
2 warnings
1 module with missing tables
20 module with mis-matching tables

To manually "fix" 20+ missing and/or mis-matching tables is virtually impossible; I analyzed one critical issue with the 'flag' module which took me several days to repair, digging after every issue would take me weeks per site; other unsolved schema problems arise from broken core database updates (like 'book' module), and even 'cck' has problems with database updates that don't run properly; heavy stuff like this is out of my league - I know the problems are there, but I can't fix them. The 'schema' module does not really help me with that, except that it allows to validate a "hunch".

In regard to the 'schema' module, it'd be really helpful if the module would be not only descriptve, but could suggest procedures to fix common issues; it's functionality could be extended, e.g., to investigate CCK fields that are left after an core update as "inactive", and it could allow to delete CCK field definitions that are no longer used by any content type; also I believe that basic schema validation needs to go into core, but that's another topic.

I don't know how active this module is maintained, but I'm willing to help in areas where I can provide help, and I'd like to activate this support (documentation? feature?) request. On the other hand, if the maintainers feeld that 'schema' should be a pure descriptive developer tool, we could (should) close the issue as "won't fix". Your ideas and suggestions are greatly appreciated!