Did manual update from d7beta1 -> d7beta2:
1. emptied the drupal installation directory (drastic and complete!)
2. Copied the beta2 (is it true, that there is no more .htaccess?)
3. started drupal 7 in browser and provided database access settings
4. started the site and logged in as admin
5. started the suggested upgrade procedure:
The following updates returned messages
filter module
user module
Update #7015* Failed: PDOException: %message in db_change_field() (line 2895 of /var/www/drupal/includes/database/database.inc).
block module
Update #7007* Failed: PDOException: %message in db_change_field() (line 2895 of /var/www/drupal/includes/database/database.inc).
text module
Update #7000* Failed: PDOException: %message in db_change_field() (line 2895 of /var/www/drupal/includes/database/database.inc).
system module
taxonomy module
Update #7009* Failed: PDOException: %message in db_change_field() (line 2895 of /var/www/drupal/includes/database/database.inc).
I am using Postgres as Database system.
Comment | File | Size | Author |
---|---|---|---|
#39 | Screenshot-7.png | 138.93 KB | chalet16 |
#39 | Screenshot-6.png | 127 KB | chalet16 |
#39 | 951116-update.patch | 3.01 KB | chalet16 |
#33 | drupal7-filter-fomat-test-update.patch | 1.2 KB | chalet16 |
#31 | drupal7-filter-fomat-test.patch | 1.07 KB | chalet16 |
Comments
Comment #1
Damien Tournoud CreditAttribution: Damien Tournoud commentedThe root cause of your problem is probably that you incorrectly updated a database from alpha to beta1, and as a consequence the beta1 to beta2 upgrade path is not run correctly. Those updates should not run at all if you are really on beta1.
But. We broke some exception messages that we need to fix. Attached patch restores the proper message placeholder. For reference: we broke that in #642160: Make debug() message work better (usable). Bumping to critical because it makes the whole upgrade path undebuggable.
Comment #2
Drops CreditAttribution: Drops commentedI confirm that I updated from Alpha to Beta1 and I might have skipped the update script.
Comment #3
Damien Tournoud CreditAttribution: Damien Tournoud commentedRefocusing this issue.
Comment #4
lukeprentice CreditAttribution: lukeprentice commentedi have installed beta1 fresh, then tried to run the updates for beta2 this morning.
i had the same errors, applied damien's patch and got this error 4 times.
here is the complete report:
i am using postgres 8.4.4
looks like "format" is of type "bigint" in my postgres db.
i suspect perhaps postgres doesn't like the field change.
Comment #5
Damien Tournoud CreditAttribution: Damien Tournoud commentedI spined-off the update exception message patch in #951486: Invalid placeholders in exception messages during update.
Let's refocus this one on the exception on int -> varchar conversion on PostgreSQL.
Comment #6
grobe CreditAttribution: grobe commentedI experienced the same issue, upgrading from beta1 to beta2 on postgres.
I have the beta2 code running now nevertheless, and it seams to be ok.
However I would like to know whether this leaves me with a problem in my database. Should I revert to beta1? Or can I continue using beta2 even though the database was not properly updated and will I be able to apply future updates?
Comment #7
Stevel CreditAttribution: Stevel commentedThe reason for the failure lies in the following line (for the block module update):
Check constraints:
"block_custom_format_check" CHECK (format >= 0)
In which a comparison varchar >= int takes place after the conversion. The solution is to remove the check when changing from an unsigned int to something non-int, or when staying at int, but unsigned => TRUE is missing in $spec.
Comment #8
Stevel CreditAttribution: Stevel commentedThis patch removes/adds the necessary check constraints on db_change_field
Summary of the patch:
- Add a function queryFieldInformation($table, $field) to DatabaseSchema_pgsql which retrieves information about the existing checks for a field
- Execute processField on the $spec in changeField() instead of duplicating code, also handles setting the correct datatype for unsigned int
- Add support for lenght/precision in changeField()
Comment #9
Stevel CreditAttribution: Stevel commentedComment #10
grobe CreditAttribution: grobe commentedI still observe this on Postgres after updating to 7.0rc1 today.
Comment #11
Stevel CreditAttribution: Stevel commentedThat's because it's not fixed in RC1 :)
Putting back to 7.x-dev and tagging.
Comment #12
grobe CreditAttribution: grobe commentedIs this error message related to the issue? It looks to me like string and integer fields are messed up in some places, so I did not want to open a new issue. I am running Drupal 7.0-rc1 with Postgres as database backend.
I got this when adding terms to a vocabulary, but I get similar messages whenever adding blocks / terms and such related to the content filter field.
Cheers, Lars.
Comment #13
Stevel CreditAttribution: Stevel commented@grobe: Did you run the latest database updates? If so, it could be related, yes.
Comment #14
grobe CreditAttribution: grobe commented@Stevel: I ran the update.php script but got the well-known errors for several modules that were reported for rc1 on postgres. Affected modules are taxonomy, block, user and text. Should I get a dev-snapshot to rerun update.php?
Comment #15
Stevel CreditAttribution: Stevel commented@grobe: Please try -dev or cvs HEAD with the patches from #30 in #710858: Meta issue: fix the remaining PostgreSQL bugs applied to it, and try the upgrade again.
Comment #16
grobe CreditAttribution: grobe commentedI assume that today's head already has the patch applied? Running update.php now results in
Edit: I should mention that I have a 8.3 installation of Postgres here.
Comment #17
Stevel CreditAttribution: Stevel commentedHEAD only has the patches marked as fixed (green / strike through) applied. Apply the other patches manually and then try to perform the upgrade again (from a copy of the Drupal 6 database).
Comment #18
grobe CreditAttribution: grobe commentedHi Stevel, thank you for pointing me at that, I obviously misunderstood the status of the patch. Unfortunately I do not have a Drupal 6 database. I started the affected website (from scratch) once beta1 was out, as that was the first release to have support in the upgrade chain for coming 7.x releases. Cheers, Lars.
edit:
OK, I still applied the patches, and update.php completed. There was a notice that update for the four modules mentioned before resulted in messages, still these were void. I could not observe anything suspicious in my postgres logs neither. Looks like the problem is fixed.
Patches applied:
Comment #19
Damien Tournoud CreditAttribution: Damien Tournoud commentedThis is exactly what DatabaseSchema::getPrefixInfo() is about.
Other then that, this patch looks good to me (I haven't tried to understand the introspection query). Nice clean up of the alter field.
Comment #20
Stevel CreditAttribution: Stevel commentedChanged the patch to use getPrefixInfo.
Comment #21
Damien Tournoud CreditAttribution: Damien Tournoud commentedOk so, to make it short: this patch implements the missing bits of changeField() that are needed for PostgreSQL: make it on par with addField() in regard to how we process unsigned fields and remove the constraints before recreating them.
Good to go.
Comment #22
Dries CreditAttribution: Dries commentedReturning an object with one member variable is bit weird. Why don't we return the checks directly? That looks more elegant to me.
Comment #23
webchickComment #24
Stevel CreditAttribution: Stevel commentedReturning an object makes it consistent with queryTableInformation, and it makes it possible to add more data should it be required later.
Comment #25
Darren OhAnything for Dries.
Comment #26
Darren OhIn my opinion this is critical.
Comment #27
chx CreditAttribution: chx commentedSuch opinion requires a strong argument in the form of an issue summary.
Comment #28
Darren OhThe ability to update is an essential feature of Drupal. This bug prevents updates and is therefore critical.
Comment #29
webchick...not in postgres.
However, I'm happy to commit this when it's RTBC.
Comment #30
chx CreditAttribution: chx commentedDamien said in IRC just two three days ago that he considers PostgreSQL unsupported in Drupal 6 and update at your own risk. On the other hand, I filed one of the upgrade path issues as a GCI task -- does this solve all of them failing? Care to maybe run all upgrade tasks in a terminal and attach a screenshot so we can see it passes w/o installing pgsql?
Comment #31
chalet16 CreditAttribution: chalet16 commentedPatch (GCI Task)
(Tested on Ubuntu 10.10: PHP 5.3.3-1ubuntu9.1 PostgreSQL 8.4.5-0ubuntu10.10)
Comment #32
webchickCould you elaborate a bit on your solution? This could do with some comments, because I don't quite understand what's happening here.
Also, minor nit-pick:
There should be a space between if and ( according to the coding standards.
Comment #33
chalet16 CreditAttribution: chalet16 commentedUpdate patch
Comment #34
chx CreditAttribution: chx commentedComment #35
Stevel CreditAttribution: Stevel commentedThis doesn't account for fields changing from e.g. unsigned int to signed int, or from anything signed / not numeric to an unsigned type.
It also assumes that check conditions follow a specified naming convention, but there is no name explicitly given to the check on creation. Furthermore, when a field is renamed, the name of the check constraint does not change.
Comment #36
chx CreditAttribution: chx commentedLet's get back to #25 ?
Comment #37
chalet16 CreditAttribution: chalet16 commentedI'm recreating patch now testing with schema api and upgrade path test.
Comment #38
Stevel CreditAttribution: Stevel commentedAs per #30 and #36, here are the test results for the upgrade path testing of #25 (postgresql 9.0.2 / PHP 5.3.3). All tests passing:
Test run started: Sunday, December 26, 2010 - 14:59
Test summary:
-------------
Comment upgrade path 32 passes, 0 fails, 0 exceptions, and 13 debug messages
Basic upgrade path 78 passes, 0 fails, 0 exceptions, and 26 debug messages
Filter format upgrade path 38 passes, 0 fails, 0 exceptions, and 14 debug messages
Node body upgrade path 43 passes, 0 fails, 0 exceptions, and 17 debug messages
Poll upgrade path 218 passes, 0 fails, 0 exceptions, and 37 debug messages
Locale upgrade path 167 passes, 0 fails, 0 exceptions, and 60 debug messages
Taxonomy upgrade path 1265 passes, 0 fails, 0 exceptions, and 50 debug messages
Upload upgrade path 37 passes, 0 fails, 0 exceptions, and 11 debug messages
Test run duration: 3 min 47 sec
Comment #39
chalet16 CreditAttribution: chalet16 commentedI don't know that my patch will help or not but anyway
- pass all upgrade test
- pass schema api test (need to use with http://drupal.org/node/1007448)
Comment #40
Darren OhYour patch may help if you will explain why it is an improvement.
Comment #41
Stevel CreditAttribution: Stevel commentedLet's get this in then. The patch in #20 was RTBC before, and #25 adresses Dries' comment.
So this is RTBC for #25.
Comment #42
webchickchalet16's fix is a lot less invasive, so I'd love Stevel or Damien to take a look at that and see if it makes sense.
For now though, since I need to roll a new RC and I'd like that to have a working PostgreSQL upgrade path, committed #25 to HEAD, with a minor comment fix.