Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I got this when running database updates on my site:
Update #7005
* Failed: PDOException: SQLSTATE[42804]: Datatype mismatch: 7 ERROR: default for column "quality" cannot be cast to type real: ALTER TABLE {mollom} ALTER "quality" TYPE real USING "quality"::real; Array ( ) in db_change_field() (line 2892 of /usr/srv/www/misc/mikkel.hoegh.org/includes/database/database.inc).
Comment | File | Size | Author |
---|---|---|---|
#19 | 935258-better.patch | 1.16 KB | Josh Waihi |
#13 | 935258-change-default-nulls.patch | 1.31 KB | Stevel |
#11 | 935258-change-default-nulls.patch | 1.34 KB | Stevel |
#6 | 935258-change-default-nulls.patch | 1.34 KB | Stevel |
#5 | 935258-change-default.patch | 1.31 KB | Stevel |
Comments
Comment #1
sun1) With "upgrade", do you mean upgrading from D6 or merely an earlier version of D7?
2) On which database is this? Doesn't look like MySQL?
It's possible that you found a Drupal core bug -- in which case this issue should be moved into the core queue.
Comment #2
mikl CreditAttribution: mikl commentedThis was from the alpha/beta2 (don’t remember, those releases have been removed since then) release of Mollom for Drupal 7 on a fresh install.
The database is indeed not MySQL, but PostgreSQL.
Comment #3
sunThe module update tries to perform the following (which works as intended on MySQL):
The db_change_field() leads to the error message:
Looking through the postgres driver, I see that code in DatabaseSchema_pgsql::changeField():
But based on the error message, it looks like neither ::createFieldSql() nor ::fieldSetNoDefault() is invoked from ::changeField().
In other words:
1) A previously specified 'default' is not removed or changed prior to changing the column type.
2) Somehow, the passed in $spec and ::createFieldSql() is not invoked or used, so I wonder how more subtle column differences are actually applied on PostgreSQL? E.g., nothing seems to happen when varchar(64) is changed to varchar(255)...?
Comment #4
Stevel CreditAttribution: Stevel commenteddoh! Subscribing this so I can come back to this when I have some more time.
Comment #5
Stevel CreditAttribution: Stevel commentedHow is this for changing defaults?
The second remark from sun was fixed in #951116: db_change_field() fails to convert int to varchar on PostgreSQL I believe.
Comment #6
Stevel CreditAttribution: Stevel commentedNew patch to account for 0, false and other 'empty' variables as default values.
Comment #8
Stevel CreditAttribution: Stevel commented#6: 935258-change-default-nulls.patch queued for re-testing.
Well, how's that... A change in the DatabaseSchema for Postgresql causes test failures on mysql...
Comment #9
Stevel CreditAttribution: Stevel commentedChanging title to reflect the actual bug. Also raising to major there are contrib modules (e.g. mollom) for which the upgrade path fails because of this.
Comment #10
Crell CreditAttribution: Crell commentedThat's not the right syntax for array_key_exists(). See:
http://www.php.net/array_key_exists
I think
array_key_exists('default', $spec)
should be sufficient.Powered by Dreditor.
Comment #11
Stevel CreditAttribution: Stevel commentedUpdated the patch. The isset || array_key_exists seems to be a common pattern in drupal core for efficienty reasons (as far as I understood it).
Comment #12
sunMissing trailing period.
Actually, I don't think that NULL is a valid value for 'default', as that would translate into 'not null' => FALSE instead. Therefore, the isset() should be sufficient.
Powered by Dreditor.
Comment #13
Stevel CreditAttribution: Stevel commentedYes, you are right. NULL is the default default (twice, yes), so we don't have to set a default explicitly if it is NULL. Updated patch again.
Comment #14
sunUnless @Crell disagrees, this looks ready to fly for me.
Comment #15
webchickWe need someone to test the pgsql upgrade path.
Comment #16
Josh Waihi CreditAttribution: Josh Waihi commentedI get as far as visting update.php and get the following error:
Update:
DatabaseSchemaObjectDoesNotExistException: Cannot set default value of field actions.description: field doesn't exist. in DatabaseSchema_pgsql->fieldSetDefault() (line 397 of /home/josh/drupal/935258/includes/database/pgsql/schema.inc).
Comment #17
Stevel CreditAttribution: Stevel commentedAre you sure you don't get the error without the patch applied?
How are indexes related to default values? This belongs in it's own issue I think (is this the same bug as #935570: Cannot add "system list" because "system" already exists?)
Comment #18
Josh Waihi CreditAttribution: Josh Waihi commentedsorry, that was the wrong error (is was after I refreshed). Its actually:
DatabaseSchemaObjectDoesNotExistException: Cannot set default value of field actions.description: field doesn't exist. in DatabaseSchema_pgsql->fieldSetDefault() (line 397 of /home/josh/drupal/935258/includes/database/pgsql/schema.inc).
Comment #19
Josh Waihi CreditAttribution: Josh Waihi commentedWas a php variable error. $field was being used after $field had been renamed to $new_field.
Comment #20
Stevel CreditAttribution: Stevel commenteddoh, of course :) If you don't have any further comments, I guess this is RTBC then.
Comment #21
Stevel CreditAttribution: Stevel commentedComment #22
catchComment #23
Dries CreditAttribution: Dries commentedI don't have PostgreSQL to test on, but decided to commit this to 8.x and 7.x. Thanks.
Comment #24
Josh Waihi CreditAttribution: Josh Waihi commentedThanks Dries :)