1545: Upgrade from 1.0.5.1 to 1.5beta1 fails evolution
- ThirdParty
- Review Board
| Karr*****@gmai***** (Google Code) (Is this you? Claim this profile.) | |
| Sept. 20, 2010 |
What version are you running? Upgrading from 1.0.5.1 to 1.5beta1 running against PostgreSQL 8.3.8 What's the URL of the page containing the problem? N/A What steps will reproduce the problem? 1. Install the new version of ReviewBoard 2. Run rb-site upgrade /path/to/site What is the expected output? What do you see instead? I would expect the upgrade to complete successfully. What I actually get is this: Project signature has changed - an evolution is required Error applying evolution: cannot ALTER TABLE "diffviewer_diffset" because it has pending trigger events What operating system are you using? What browser? Red Hat Enterprise Linux 5.4
My suspicion is that I'm hitting this bug from Django/PostgreSQL: http://code.google.com/p/django-evolution/issues/detail?id=74
-
+ ThirdParty
I'm also having this problem upgrading from the 1.0.X series to 1.5 stable. Running postgres 8.3, django 1.2.3. Is there a simple fix for this? Or should I look through rb-site's code and see which tables need to be altered and do that by hand?
Okay -- update -- I got it working by manually running the migration. Basically, I symlinked my local_settings.py into the reviewboard egg directory and ran # ./manage.py evolve --hint to make sure that everything was working alright. Then, # ./manage.py evolve --sql to get the output of the migration SQL that I'll need to apply. It turns out that the migrations don't apply on Postgres because there are non-transactional safe changes that are being made. In this case, updating a table and then altering it cannot be done within the same transaction. The solution was to take the sql generated by evolve and carefully put whatever we could into transactions and commit after every update. After this, we had a working site. However, using postreview extension for mercurial we ran into 500s. Looking through the logs I found that it was a Database Permissions error. I queried around in our pgsql server, and sure enough, a new table we created in the reviewboard table was owned by postgres (since that was the user we used to perform the migration). I just changed the ownership of this one table, and everything has been running well since.
Thanks, Gavin - manually generating and running the evolution SQL also worked for me.
How do you stay in sync with future changes after manually running the sql?
That's a good question. I haven't played around with recent upgrades. I assume that the schema will be in a predictable format for future evolve migrations, and should therefore "just work". The only difference was how the transaction commits were ordered with updates. Have you had issues with subsequent upgrades?
I think the problem we are seeing is that the django_ tables still think the models and tables are not in sync because the manual sql does not update the django_ tables. We do not get additional rows in django_evolution and no update to django_project_version
Yeah, I can't say that I've tried to get that working. One thing that strikes me as possible is to repeat the process of generating the SQL and manually applying it -- but then you'd be stuck doing that forever. There might be a clever way of returning django_tables and django_project_version into phase with the models, but I'd have to look into it. Good luck if you get there before I do.