I've updated the sections module to D6 and tried to test the update process.

1. i set the schema version to "0"
2. removed the two columns ('visibility' and 'weight') that will be added in sections_update_1()
3. executed update.php and there are errors thrown telling me the columns 'visibility' and 'weight' do not exist, what is correct, but this schema update should run first and then the hook_init.

Here is the error:

user warning: Unknown column 'visibility' in 'field list' query: SELECT path, status, visibility, theme, weight FROM sections_data WHERE status=1 ORDER BY weight in C:\Inetpub\wwwroot\drupal6\includes\database.mysqli.inc on line 154.

It looks like the update.php shouldn't fire any module hook_* in general and especial hook_init in my case. Any hook should contain SQL requests that requires to run schema update first.

Comments

profix898’s picture

profix898 commented

I havent tried that, but are you sure you are using the new hook_update_N naming convention? Shouldnt sections_update_1() be sections_update_6001() now?

hass’s picture

hass commented

i don't think so. System.module have schema version of 6000 or higher, sections is version 2.

1. If a site is D5 and have schema version 2
2. i'm updating to D6 and now sections have schema version 3 - i cannot re-run sections_update_2() or i get a bunch of errors and this re-run will happen if i change to sections_update_6002, too.
3. D6 must only run sections_update_3() and upgrade schema version 2 to 3

profix898’s picture

profix898 commented

I must admit I cant read this exactly from the docs (http://drupal.org/node/114774#update-n). But I think the update from 5.x to 6.x should be in hook_update_6000(). If you are then updating the module during 6.x lifetime you start by increasing the number, e.g. 6001, 6002, ... The second major release of a module 6.x-2.x would have 6200, 6201, 6202, ...
In your case (you want the update to be also available for the 5.x branch, right?) the user should update to the most recent 5.x version before he/she switches to Drupal 6. This way hook_update_2 is executed by D5.x before D6 is installed. Starting from D6 you may have concurrent updates for different branches, but this is not possible atm AFAIK.

hass’s picture

hass commented

Found this in core: function comment_update_1(). Looks different. I think the update doc contains only an example build on systems module...

In your case (you want the update to be also available for the 5.x branch, right?)

Yes, but maybe some schema changes are only done in D6, too. Or i don't like to alter a stable version and don't plan to release any 5.x!?

the user should update to the most recent 5.x version before he/she switches to Drupal 6.

Well we can tell this, but no one like to do this... maybe the module is broken in a later 5.x release, but the D6 isn't (only as an example). Or i don't like to do testing two times - once latest D5 release and latest D6.

This way hook_update_2 is executed by D5.x before D6 is installed. Starting from D6 you may have concurrent updates for different branches, but this is not possible atm AFAIK.

Hmm. I don't like such bad update ways for users... sometimes it could be possible someone is upgrading from D47 to D6 and don't like to update to D5 first.
I think this upgrade way was different in past. An update was possible without forcing someone to upgrade in steps like this, isn't it?

But, however the update function numbering is - this problem cannot be solved by changing the version numbers. The problem is that a modules hook_init is executed by update.php on startup and this result in errors like the above (caused by a SQL select statement in sections_init() ). The Update.php output's errors, while some columns are missing. This have nothing to do with the numbering.

Update.php logic should be:
1. boot
2. do not load anything from the drupal system except what is essential for running the update.
3. after this is finished, module hooks can be executed, but this befor the DB updates are finished

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Closed (works as designed)

hook_init is firing when it always does - right after bootstrap complete. it doesn't make sense to special case the update page, IMO. i haven't looked too closely though ... i suggest you be more careful inyour init code so it doesn't fail in this case (i assume thats what the problem is - you didn't say).

hass’s picture

hass commented
Status: Closed (works as designed) » Active

Sorry, it's not such easy. If you execute SQL requests with hook_init, what may be normal this comes up. This new D6 hook_init is now the if (!$may_cache) { we used in past and now do not exists anymore. So what i'm doing here is i'm loading something from database... this is how hook_init will be used, isn't it? Something wrong with this? Should i check or execute functions that are inside mymodule_update_N() on every hook_init() only to make sure the modules schema is up-to-date - i don't think so!

So if i'm updating the module schema hook_init get's executed and this is a no-go. If the module schema is not up-to-date the module shoudn't be loaded or i get errors. Now i'm using hook_init, someone else useing different hocks and will have the same troubles. How should my module know if an schema update is required or not? only mymodule.install does this job, isn't it? update.php needs to take care about possible schema updates. First I need to be able to update the schema's and after this update.php may fire hook_*.

How should a module ever workaround this if this is not taken in account in update.php? We only get broken update.php's with this...

hass’s picture

hass commented

If you'd like to take a look to modules code: http://drupal.org/node/95181

chx’s picture

chx commented
Status: Active » Closed (won't fix)

4. Disable contributed modules and switch to a core theme

from UPGRADE.txt