So. At the DC CPH code sprint, and I'm trying to test the D6->D7 upgrade path in an attempt to debug/test #706842: Improve comments for the taxonomy upgrade path. I was using an existing D6 site installation that had quite a few contrib modules installed. The upgrade bailed with the following error.
Fatal error: Call to undefined function field_attach_delete_bundle() in /home/tom/workspace/d7/modules/node/node.module on line 634
The backtrace is basically the same as in #685572: system_update_7008() is broken:
drupal_flush_all_caches() at the end of the installation will trigger a node_types_rebuild(), that will call node_type_delete(), that will call comment_node_type_delete(), that will fail with a call to field_attach_delete_bundle().
By inserting print_r('<pre>'.print_r(debug_backtrace()
at the top of node_type_delete(), I was able to ascertain that the problem comes down to the fact that in update_fix_d7_requirements() the role_permissions table is built, and the maxlength of the permission field is 64 chars. There is no such limit in D6, and my installation has several permissions that go over this limit. Because of this, the entire insert into the role_permissions table fails. This seems to have a knock on effect, and bad things happen as a result. By adjusting the field length to 128 chars, I was able to ensure that this insert ran successfully (see attached patch). And in doing so, I was able to proceed much further along the upgrade.
Comment | File | Size | Author |
---|---|---|---|
permissions.patch | 1.17 KB | mrfelton | |
Comments
Comment #1
mrfelton CreditAttribution: mrfelton commentedComment #2
bjaspan CreditAttribution: bjaspan commentedThat sounds like a nice bit of debugging, good job. I'd like to understand clearly why the limit on role name length caused field.attach.inc not to be loaded (perhaps because the whole field module was not loaded?). It may be that there is some other underlying bug that got triggered by the insert failure into the role_permissions table, and we don't want to lose this opportunity to find it.
We should almost certainly fix the length limit, though. Anyone know why it is there now?
Comment #3
catchIssue is this one #73874: Normalize permissions table. there was never any limitation whatsoever in D6 since it was just comma-separated in a big text field, and no discussion in that issue, so probably just underestimated the longest permission length. Don't see a problem just raising the limit, this will need a head2head issue once it's in.
Comment #4
bjaspan CreditAttribution: bjaspan commentedI'm fine with this commit but as per #2 I want to understand why it triggered field.attach.inc not being included, so please let's not close the issue until we do.
Comment #5
webchickCommitted #0 to HEAD. Thanks! Marking back to needs work per #4.
Comment #6
mrfelton CreditAttribution: mrfelton commentedHold on, does this not need an update hook for existing drupal 7 installations? Or, is that just or being supported now?
Comment #7
bjaspan CreditAttribution: bjaspan commentedNo update hook needed for head to head updates. Issue is still open per #4.
Comment #8
catchIt's not supported until a beta, but I opened #895060: #894898 Increase permission length restriction from 64 to 128 for head2head.
Comment #9
catchRetitling this, downgrading to major, taking out of the upgrade path queue. Agree it'd be good to look closer at why this happened in this particular way.
Comment #10
bjaspan CreditAttribution: bjaspan commentedI think the issue is that it kills an update function, after which basically all bets are off. I sorta decided I didn't care to look further, but I'm okay with it being non-critical and open.
Comment #11
webchickTalked to Barry, and he's pretty sure that this is because the upgrade path fails so all sorts of oddness happens. So he's comfortable marking this fixed.
Comment #12
bjaspan CreditAttribution: bjaspan commentedAngie and I are sitting right next to each other and yet still managed to mis-communicate. :-) Moving this back to open/major with her blessing.
Comment #13
discipolo CreditAttribution: discipolo commentedjust thought i'd drop this in here before proceeding further:
when updating a d6.17 German/Englsh localized site to latest cvs version of d7 after applying
http://drupal.org/node/706842#comment-3359278
and http://drupal.org/files/issues/permissions_21.patch
i get :
An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: http://phtv.kukuma.info/drupal/update.php?id=17&op=do StatusText: OK ResponseText: Fatal error: Call to undefined function locale_language_negotiation_info() in /home/rosenstrauch/phtv.kukuma.info/drupal/modules/locale/locale.install on line 89
errorpage:
Update #7059
* Failed: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'db_kukuma_phtv.file_usage' doesn't exist: SELECT 1 AS expression FROM {file_usage} file_usage WHERE (fid = :db_condition_placeholder_0) AND (module = :db_condition_placeholder_1) AND (type = :db_condition_placeholder_2) AND (id IS NULL ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => 83 [:db_condition_placeholder_1] => file [:db_condition_placeholder_2] => node ) in file_usage_add() (line 608 of /home/rosenstrauch/phtv.kukuma.info/drupal/includes/file.inc).
The update process was aborted prematurely while running update #7001 in locale.module
besides all that: no idea if the taxonomies are still associated - all my contenttypes are in features and contrib... gotta find those
Comment #14
mrfelton CreditAttribution: mrfelton commented@discipolo: Update your CVS checkout. The locale issue was resolved in #894900: Call to undefined function locale_language_negotiation_info() on site upgrade
Comment #15
discipolo CreditAttribution: discipolo commentedok. you are too fast :-) keep it up go sprint!
Comment #16
discipolo CreditAttribution: discipolo commentedhm .. with new ccvs version i get:
Update #7059
Failed: DatabaseSchemaObjectExistsException: Table file_usage already exists. in DatabaseSchema->createTable() (line 621 of /home/drupal/includes/database/schema.inc).
so it also cannot complete user module :
7013 - Add user module file usage entries.
did i miss an issue in queue again?
Comment #17
sun.core CreditAttribution: sun.core commentedThe already committed patch fixed the issue at hand, so if there's any follow-up debugging or analysis work to do, then that should happen in a separate issue.