While upgrading from D6 to D7, ran into this error. Looks like it's because the delta used for the block is too long.

PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'delta' at row 1:

INSERT INTO {block} (module, delta, theme, status, weight, region, pages, cache) VALUES (:db_insert_placeholder_0,
:db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4,
:db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7); Array
(
    [:db_insert_placeholder_0] => jump_menu
    [:db_insert_placeholder_1] => jump_menu_menu-meganav-sub-pr-desktop
    [:db_insert_placeholder_2] => garland
    [:db_insert_placeholder_3] => 0
    [:db_insert_placeholder_4] => 0
    [:db_insert_placeholder_5] => -1
    [:db_insert_placeholder_6] => 
    [:db_insert_placeholder_7] => -1
)

Either make the module-specific portions of the delta shorter or take into account the 32 character limit of delta when writing to the DB.

Comments

doublejosh’s picture

doublejosh commented

Need to preserve the module name space and designate menu vs local task mode. Menus no longer have IDs in D7 so that they are namespace dependent and not serial, so I'd have to opt for a hash to safely shorten. However, I'm relying on the menu name in the delta to know what menu to render.

Would be nice to hash the menu name, like you can with numbers to shorten them, which with capitals might work... but it seems silly.
[link] [link]

I guess deltas will have to include as much as they can of the menu name and allow partial matches if at the end of the delta. Not a lot of options beyond a new table and that seems like a bad idea.

Delta will be like: "jump_menu-m_menu-name" and "jump_menu-local-tasks". This provides 15 chars for menu names which is plenty in most cases and at least enough to be a good clue in HTML output. Writing an update to carry out the change to block deltas.

Step one (shorter deltas) commited 67ef7b4e5133fa0fde8f01fd3f4cc8441e255512

doublejosh’s picture

doublejosh commented
Title: PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'delta' at row 1: » Block delta too long with some menus
doublejosh’s picture

doublejosh commented
Status: Active » Needs work
doublejosh’s picture

doublejosh commented

Shorter deltas committed to 7.x-1.x branch 209fa92f2eb9614f8e9f7e75967773bb80f4ff5c

Imagine I'll also need to create a dev branch of the D6 version which chops the deltas for the automated upgrade path. Yes?

doublejosh’s picture

doublejosh commented
Status: Needs work » Needs review
iamEAP’s picture

iamEAP commented
Status: Needs review » Reviewed & tested by the community

That did it. No D6 changes necessary, it seems.

Note that I've added a followup issue to this that's largely unrelated, but still relates to the upgrade path: #1517070: Should blocks created in D6 be purged in a D7 update function?

doublejosh’s picture

doublejosh commented

What I meant was to update (mySQL) those blocks within 6.x-dev upgrade step so they would be in the right regions and themes after the update.

Otherwise, the blocks will be there in D7, they just won't be placed... if done via the core block system.
(this is beyond the use-case we're specifically dealing with.)

iamEAP’s picture

iamEAP commented

Ah, I see.

Are you going to / have you already address/ed the block delta length in the D6 version? If so, I think the best upgrade path is: an update in 6 that edits the block deltas, then not worrying about it at all in D7.

doublejosh’s picture

doublejosh commented
Version: 7.x-1.3 » 6.x-1.2
Status: Reviewed & tested by the community » Needs work

Altering this issue to provide a 6.x-dev release with an upgrade function to truncate existing block deltas.

doublejosh’s picture

doublejosh commented
Status: Needs work » Closed (won't fix)

Not an immediate need for us.

Unless someone actually needs an upgrade path to preserve blocks in position for core block arrangement this won't get a fix.

If you need to preserve long menu block deltas during an upgrade to D7, feel free to reopen.

doublejosh’s picture

doublejosh commented
Status: Closed (won't fix) » Fixed
doublejosh’s picture

doublejosh commented

Actaully please open up the other issue if anyone has this request.
#1517070: Should blocks created in D6 be purged in a D7 update function?

Status: Fixed » Closed (fixed)

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

freeform.steph’s picture

freeform.steph commented

I am having an issue where menus with a long name (example: menu-unwrapped-gift-categories) are appearing in the blocks ui page, but if I try to assign them to a region the block fails to save in the desired location, it remains disabled.

After reading this post, I believe it's the same issue (but not positive). I took a look at the blocks table in the db and found that the menus that had long names were actually missing from the listings for jump menu, what I mean is:

select * from blocks where module = 'jump_menu';

showed that I had 11 entries for jump_menu for each theme, meanwhile there are 15 menus, and 15 jump menu blocks appearing on the blocks administration page.

I created a new menu (with a very short name) and used an sql statement to switch all the items from the menu with the long name to the menu with the short name, and was then able to enable my new jump menu block.

But, then, now I have the issue with parents missing if they have the same url as a child: http://drupal.org/node/1510294 I will go deal with that now ;)

freeform.steph’s picture

freeform.steph commented
Issue summary: View changes

move error into post

donquixote’s picture

donquixote commented

See also #2182201: block_schema(): Change block.delta from varchar(32) to varchar(64)