Created a content type for Table and proceeded to try to create a node. On [Save], I got the following:
PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: 'full_html' for column 'field_table2_format' at row 1: INSERT INTO {field_data_field_table2} (etid, entity_id, revision_id, bundle, delta, language, field_table2_value, field_table2_format) 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] => 1 [:db_insert_placeholder_1] => 15 [:db_insert_placeholder_2] => 46 [:db_insert_placeholder_3] => table [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => a:27:{s:8:"cell_0_0";s:3:"Day";s:8:"cell_0_1";s:4:"Time";s:8:"cell_0_2";s:5:"Level";s:8:"cell_0_3";s:8:"Location";
s:8:"cell_0_4";s:0:"";s:8:"cell_1_0";s:0:"";s:8:"cell_1_1";s:0:"";s:8:"cell_1_2";s:0:"";s:8:"cell_1_3";s:0:"";
s:8:"cell_1_4";s:0:"";s:8:"cell_2_0";s:0:"";s:8:"cell_2_1";s:0:"";s:8:"cell_2_2";s:0:"";s:8:"cell_2_3";s:0:"";
s:8:"cell_2_4";s:0:"";s:8:"cell_3_0";s:0:"";s:8:"cell_3_1";s:0:"";s:8:"cell_3_2";s:0:"";s:8:"cell_3_3";s:0:"";
s:8:"cell_3_4";s:0:"";s:8:"cell_4_0";s:0:"";s:8:"cell_4_1";s:0:"";s:8:"cell_4_2";s:0:"";s:8:"cell_4_3";s:0:"";
s:8:"cell_4_4";s:0:"";s:7:"rebuild";a:3:{s:10:"count_cols";i:5;s:10:"count_rows";i:5;s:7:"rebuild";s:13:"Rebuild Table";}s:6:"import";a:2:{s:29:"tablefield_csv_field_table2_0";s:0:"";s:22:"rebuild_field_table2_0";s:10:"Upload CSV";}} [:db_insert_placeholder_7] => full_html ) in field_sql_storage_field_storage_write() (line 447 of /home/spiralsa/public_html/drupal7/drupal-7.0-beta3/modules/field/modules/field_sql_storage/field_sql_storage.module).
This problem seems to have been introduced with drupal-7.0-beta3 as I had no problems with drupal-7.0-beta2.
Comments
Comment #1
kevin hankens commentedOh crud. Yup, looks like the issue for turning filter format deltas into machine names. Well, the code fix is pretty easy, but I have a feeling that the database fix will be a bit tougher. I'll do some research to see if there is a convenient way to do it in an update function.
This patch will fix new installs... let me know if it works for you! :)
Comment #2
Critical Tinkerer commentedApplied the patch but same error (probably due to *not* being a new install).
Don't have time to check it on a new install just now, sorry. Maybe have time to fiddle with it in the next 24 hours.
Comment #3
kevin hankens commentedYeah, I'm going to work on an update script that can change the schema. In the past, the filter format, like 'Full HTML' was stored as an integer value. Now, to make things more exportable, it's being saved as a string 'full_html'. So, we need to alter the db column to store it as a varchar instead of an int. The update script will probably create a temp column, copy the values across, then alter the format column, then map the old int values to the new string values and copy back into the original column.
I'll see about getting that committed as soon as possible... hopefully tonight :)
Comment #4
kevin hankens commentedOk, looks like this one is fairly easy. I'm copying what the text field module does by using _update_7000_field_read_fields() to locate all of the tablefield fields using sql storage. Then updating those to be varchar. Previously set up input formats using deltas are still fine, but newly created formats (post beta 1, IIRC) will now be saved using their machine name.
I tested this locally, but it would help if you could do the same. You'll have to apply the patches (from the tablefield alpha3 release) and run update.php. Just, please make sure to make backups before attempting the update :)
Let me know if that works and I'll put out a new release right away.
Thanks for the help!
Comment #5
Taxoman commentedWhat is the status of this issue? Confirmed/solved/committed? Strange that an issue with critical status and seemingly fixed patch is left for over 6 months without even committed to the dev branch...
Comment #6
kevin hankens commentedThe patches were committed despite not receiving confirmation. They were verifiable, so that seemed valid enough. The issue was left open in case someone found an error in the patch. I'll close it now.
On a side note, I don't understand the meaning of your last statement. Please keep things clear and constructive. Thanks!