user warning: Table 'drupal_head.aggregator_item' doesn't exist query: ALTER TABLE aggregator_item ADD INDEX (fid) in /var/www/html/drupal_head/includes/ on line 128.

i update CVS HEAD this afternoon and ran update.php. failed on aggregator table update. this install has never had aggregator activated, so tables were never created. there should not be any attempt to update them!

notes from IRC regarding attempted aggregator table updates:

webchick> they should be in aggregator_update_1 or whatever
webchick> in aggregator.install, not system.install
eaton> Ugh, that's broken, didn't realize that someone put those updates in there :P

Members fund testing for the Drupal project. Drupal Association Learn more


webchick’s picture

Priority: Normal » Critical
Status: Active » Needs work
1.89 KB

Bumping status to critical because it will cause updates to be numbered incorrectly unless we fix this before the next db update code gets put in.

For some reason though, this patch doesn't seem to display any drop-down for aggregator module under update.php. Any ideas?

webchick’s picture

Title: update.php fails on 'no such table ... aggregator' » Non-required modules need their updates in their own files

Changing the title, as we now have a locale update in system.install; this is only going to get worse.

Heine’s picture

The problem scenarios devised in IRC with core module updates in module.install:

Suppose a user of 4.7 has locale disabled, upgrades to 4.8, then enables locale. He/she now has to run update.php again.

Suppose a user of 4.8 had locale enabled at some point; when upgrading to a hypothetical 4.8.1 that does contain a db upgrade for locale the locale table is not updated. When the user later enables locale, he/she has to run update.php again.

If we upgrade tables indiscriminately in system.install we get the problem cited by Harry Slaughter, where fresh 4.8 installs won't have certain tables.

chx’s picture

Title: Non-required modules need their updates in their own files » Core patches in the future should use db_table_exists
Status: Needs work » Postponed

You were running a HEAD->HEAD update. This is not supported.

Drupal 6 updates will need some consideration, indeed. But I think the installation system could take care of them...

For now, there is no issue because when you go on the supported path then you are upgrading from 4.7 where all tables exists.

chx’s picture

Title: Core patches in the future should use db_table_exists » Non-required modules need their updates in their own files

hm mmm i think i will keep the title.

webchick’s picture

Well... it's not as simple as db_table_exists... because if a module is initially disabled when I do the update, but then I enable it later, it still needs to execute all of the updates, no?

I also am not sure about the postponed status. We may need this as early as 5.1, if there are database changes. Seems to make sense to work it out pre-release rather than potentially holding up a bugfix release with this problem.

Zen’s picture

Version: x.y.z » 6.x-dev
Status: Postponed » Active

I think it is also important from the POV of modules being spun out of core into contrib (por ejemplo).. Bumping.

forngren’s picture

Subscribing and putting this on my radar.

kkaefer’s picture

In fact, even required module's update/install stuff can be outsourced to the respective module's install file. It's also run on install/update time.

RobRoy’s picture

Title: Non-required modules need their updates in their own files » Core modules need their updates in their own files

Yes, I agree that both required and unrequired modules need this. Eaton brought up a good point on another thread that you may want to have an installation profile that installs a custom menu.module in sites/all/modules instead of core's menu.module if you had some crazy customizations. And besides, it just makes sense and would be easier to manage.

forngren’s picture

Assigned: Unassigned » forngren
Status: Active » Needs work
6.6 KB

First steps...

pwolanin’s picture

patch looks like a good first step.

Note that I think menu module may be a special case (i.e. should be in system.install this time), since it's moving from required in D5 to non-required in D6, and it needs to coordinate with the system update that installs the new menu tables.

forngren’s picture

I'm not sure how we should proceed with the updates.

Are updates performed on non active modules? If so, then can/may/could we move the updates. But should we? I see three options here:

1) We move all updates into respective modules. This will most likely create an earth-quake-sized mess of everything and screw up everything but clean installs.
2) We move all updates since 5.x into respective modules. This will create a medium sized mess, which probably is solvable.
3) We announce for a change in 7.x an leave things for know. Just a postponed mess.

How long are updates kept in system.install? Forever?

webchick’s picture

chx and I discussed this tonight. Looks like the most straight-forward approach for our current timeline is going to be to throw db_table_exists() in various places to prevent errors during the upgrade path, and fix this properly in 7.x...

chx’s picture

Version: 6.x-dev » 7.x-dev
Category: bug » task

I reviewed 6.x and there is nothing to fix.

forngren’s picture

Assigned: forngren » Unassigned

Free issue give-away ;)

(or: I can't carry the torch no longer)

catch’s picture

Status: Needs work » Closed (duplicate)

Was fixed in this issue: