Hi Kevin,
Can I know how you performed these steps.
5. Upgrade failed with a 1050 (or similar) error because it couldn't access
some table. So I temporarily overrode django's default database handler to
use mysql + client configs in my.cnf (only a single site will reside on
this VM) via
The 1050 error from django was due to changes in to configuration file
format. Instead of using the format:
DATABASE_ENGINE = '',
DATABASE_NAME='',
.
.
.
The devs changed the format to:
DATABASES = {
'default' : {
'ENGINE': 'django.db.backends,mysql',
'NAME': '',
'USER': '',
'PASSWORD':
Christian;
Good news! Turns out the dump has been truncated by the allowed_packet_size
for mysqldump (problem with the interface between the seat and keyboard).
The upgrade succeeded, however I had to alter the engine type of all the
tables from myisam to innodb.
Can you advise on
All;
I'm having some issues performing a site migration of RB 1.5.2 to 1.7.14
from an EOL server to a VM. Here are the steps I preformed:
1. Took SQL dump of reviewboard database and restored on new system
2. Took copy of application web root and copied to new system
3. Configured memcached on
Hi Kevin,
The first red flag is that you had to do anything special with the
database. Working around those issues is going to likely just result in new
issues down the line, so for the moment, let's consider the workarounds as
not a real solution, and dig into what went wrong there.
Can you
Christian;
Thanks for the quick response. I definitely agree that the monkey-patches I
made are not fit for production (I just really wanted to make it work). As
it turns out, I didn't even need them. django-evolutions is at 0.6.9 per
your suggestion. My tables are MYISAM, which I must be
Hi Kevin,
I meant wiping it before doing any imports. Just making sure you're
importing into a fresh, empty database.
The order you'll want is:
1) Create the database (or wipe it if it already exists).
2) Import the SQL dump.
3) Run rb-site upgrade.
Christian
--
Christian Hammond -
