Changes between Initial Version and Version 1 of Ticket #11307, comment 28
- Timestamp:
- Oct 26, 2013, 1:50:48 AM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #11307, comment 28
initial v1 1 1 If you don't find the backup mentioned in comment:27, do you at least have a backup from right after the upgrade failed? I'm afraid this could get very complicated if you've been hacking at the database trying to fix it, so the most straightforward thing we can do at this point is to start with a backup from whatever the database looked like right after the upgrade failed. 2 2 3 However, if we were to start right after the upgrade failed, looking at [browser:tags/trac-0.12.5/trac/upgrades/db25.py db25.py] we can see there are 7 tables that have columns that get multiplied by 1e6, a total of 9 columns. The first thing I would want to know is whether `db25.py` was able to alter all of the columns. We can determine this by running queries like Jun showed in comment:13.3 If we were to start right after the upgrade failed, looking at [browser:tags/trac-0.12.5/trac/upgrades/db25.py db25.py] we can see there are 7 tables that have columns that get multiplied by 1e6, a total of 9 columns. The first thing I would want to know is whether `db25.py` was able to alter all of the columns. We can determine this by running queries like Jun showed in comment:13. 4 4 5 5 If all of the columns were altered, then we can set `system.db_version` to 25, and run the upgrade again. If not all of the columns were altered, then we could remove the entries from the `tables` list in `db_25.py` that **have** been altered, and run the upgrade again.