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.

CommentFileSizeAuthor
permissions.patch1.17 KBmrfelton
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mrfelton’s picture

Component: install system » update system
bjaspan’s picture

That 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?

catch’s picture

Title: Fatal error: Call to undefined function field_attach_delete_bundle() on site upgrade » Increase permission length restriction from 64 to 128
Component: update system » user.module
Status: Needs review » Reviewed & tested by the community
Issue tags: +D7 upgrade path

Issue 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.

bjaspan’s picture

I'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.

webchick’s picture

Status: Reviewed & tested by the community » Needs work

Committed #0 to HEAD. Thanks! Marking back to needs work per #4.

mrfelton’s picture

Hold on, does this not need an update hook for existing drupal 7 installations? Or, is that just or being supported now?

bjaspan’s picture

No update hook needed for head to head updates. Issue is still open per #4.

catch’s picture

It's not supported until a beta, but I opened #895060: #894898 Increase permission length restriction from 64 to 128 for head2head.

catch’s picture

Title: Increase permission length restriction from 64 to 128 » Undefined function field_attach_delete_bundle() triggered after failed permissions rebuild
Priority: Critical » Major
Issue tags: -D7 upgrade path

Retitling 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.

bjaspan’s picture

I 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.

webchick’s picture

Priority: Major » Critical
Status: Needs work » Fixed

Talked 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.

bjaspan’s picture

Priority: Critical » Major
Status: Fixed » Needs work

Angie 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.

discipolo’s picture

just 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

mrfelton’s picture

@discipolo: Update your CVS checkout. The locale issue was resolved in #894900: Call to undefined function locale_language_negotiation_info() on site upgrade

discipolo’s picture

ok. you are too fast :-) keep it up go sprint!

discipolo’s picture

hm .. 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?

sun.core’s picture

Priority: Major » Normal
Status: Needs work » Fixed

The 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.

Status: Fixed » Closed (fixed)

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