6/7 upgrade path broken

subscribe

As for me update hangs after system_update_7013()

The attached patch makes the upgrade path work but it needs more work. There are two separate problems:

1. The new core field modules (e.g. text) have the same name as their D6 versions. system_update_7027(), which installs them, therefore does not really install them. Somehow, this results in text.module's text_field_info() not being called. My current workaround is adding this line to the update before calling drupal_install_modules():

  db_delete('system')->condition('type', 'module')->condition('name', $module_list)->execute();

Like I said, it's a workaround.

2. taxonomy_update_7001() renames some tables. It appears that some update code that runs before taxo's updates is using an API function that uses the new table names. My workaround is to move taxonomy_update_7001() to system_update_7028() so it runs before all non-system modules. Not sure if this is the right solution.

I have no idea how problem #1 did not occur earlier because I am using exactly the same D6 site dump which used to work. I guess something about module installation changed that affected what happens when text.module is previously installed.

These workarounds look reasonable to me.

node_type_clear() still $node_types_clear()

Same patch but with node_type_clear() fix

Thanks for the fix.

Committed! Thanks.

So this is supposed to be fixed, isn't it?

I'm not sure but what is when taxonomy is not enabled? so it's better to check this before drupal try to rename a non-exists table.

An error occurred.
Path: ..../drupal7/update.php?id=8&op=do
Message: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal7.term_data' doesn't exist: ALTER TABLE {term_data} RENAME TO {taxonomy_term_data}; Array
(
)
in db_rename_table() (line 2205 of ....drupal7\includes\database\database.inc).

http://api.drupal.org/api/function/db_table_exists/7 is the right function.

Taxonomy module for d6 does not create tables so this tables exist anyway!

@Razorraser take a closer look to http://api.drupal.org/api/function/system_install/6

Suppose your error caused by different thing... but it's a different issue.

Even though this has been committed, I want yched or karens to review the "fix" for text.module. Will deleting the D6 entry from the system table cause problems for the full D6 CCK to Field API upgrade path?

If it does, I guess we can work out a better workaround then... provided it is pre-D7.0. Methinks we need a full CCK upgrade before then anyway...

re #14:
As outlined in #366364: [meta] Data migration from D6 contrib CCK fields to D7 Field API, D6 -> D7 upgrade of field data will need to happen with a batch process outside of update.php anyway. For instance through a contrib cck_upgrade.module, which can also implement the hooks needed to migrate text and number fields.
So I don't think the code that was committed will be problematic there.

Detail: list.module and options.module do not exist in D6 (options was optionwidgets), so technically there's no need to remove them from the system table. No harm, though.

This isn't fixed. I still get the following error:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal.term_data' doesn't exist: ALTER TABLE {term_data} RENAME TO {taxonomy_term_data}; Array ( ) in db_rename_table() (line 2214 of includes/database/database.inc).

Razorraser's patch on #12 attempts to resolve this in a way similar to system_update_6043() and system_update_6044(). In an attempt to mimic the per-table checking precedent, I have rolled a similar patch which uses a foreach instead.

@jrchamp: What kind of Drupal install are you starting with to get that error? taxonomy tables are always created during system install, so they should always exist.

@bjaspan: Likely similar to Razorraser, I'm using 7.x-dev. The taxonomy table renames had already occurred when the code was living in the module. Anyone else using dev is probably confused (it took a little bit of searching to find that this is what broke it). It doesn't hurt to put a check in there to make sure that people don't get stuck in an upgrade cycle that will never complete.

Additionally the precedent for table_exists checking exists in the functions I mentioned previously.

We do not add any code to make intra-HEAD updates work. The other module might be using table_exists because there was a legitimate way for a D6 site not to have the tables existing. If it is there in the other module to handle an intra-HEAD upgrade, then it was a mistake, but that doesn't mean we should add the same mistake here.

What about this? This moves the update to the Taxonomy module, so we know those tables exist already.

This issue doesn't need work, it is fixed. Nothing to see here, move along.

@bjaspan: Other module? I was referencing system_update_6043() and system_update_6044() in modules/system/system.install (the same file). If someone is using D6 without having those tables existing, which part of the upgrade creates those tables? I thought this file ran first.

This is not fixed. If you are on Drupal 6, uninstall Taxonomy module, so that the tables do not exist. Updating to Drupal 7 will result in what you see in the provided screenshot.

jrchamp's patch at #16 worked. Here's a reroll of it.

I see no ability to uninstall taxonomy module... You can just disable taxonomy which removes menu and UI. Taxonomy tables are inside system.install

@catch: Because system_update_7028() requires that the taxonomy tables exist in order to function correctly, this indicates that the taxonomy module is a required module. Attaching a patch to resolve this discrepancy.

Because system_update_7028() requires that the taxonomy tables exist in order to function correctly, this indicates that the taxonomy module is a required module.

No. Taxonomy's tables are created by system.install, so they always exist. The taxonomy module is optional.

@bjaspan: Ah ok. Thank you. I think I understand now. The only place that I could find the table creation was in the module install, so I'm going to have to just trust you that they exist. Sadly I'm not completely understanding how that table create process occurs in system.install. :(