Hi Joseph,
We store a version, but if it’s saying 3.0.7, then it already stored that
info. We don’t store the previous version history. You might be able to
infer the version based on any package files sitting around in Python’s
site-packages directory, if using easy_install and not pip.
Unfortun
Hi,
I Recently tried to upgrade from 2.5 to 3.0 and an error happened during
the upgrade. Mysql did not have permissions to /var/tmp or something like
that, so the database upgrade failed.
I fixed that and ran rb-site upgrade again, but there were already errors,
so the upgrade failed again.
Please don't hand-apply SQL. Generally if you need to, something deeper has
gone wrong. Hand-applying SQL without a deep understanding of how Django
Evolution works can easily result in more failures going forward.
If your database is not upgrading, work with us instead. We offer database
repair s
Hey Dan,
That looks like it's due to a half-updated database, where some changes
were applied and then there was a failure. Or, due to a forced hinted
evolution that took place at some point.
To fix it, you'd have to figure out exactly what SQL statements had applied
from which evolutions, how fa
All,
I am trying to upgrade from 2.0.20 -> 2.5.3.
I do this by taking a backup of the 2.0.20 database then importing into
MySQL and then running the rb-site upgrade.
However I get the following output:
Updating database. This may take a while.
The log output below, including warnings and e
Hi Dan,
This sort of information actually comes at a level lower than what we deal
with. It's during Django's table building process, and we have no insight
or control into any of that. I agree that this would be *very* nice (and we
need to document it), but as for creating a better error or knowi
I too had this issue (MySQL default changing from MyISAM to InnoDB).
Although I understand that this is caused by MySQL version being updated at
the same time as a Reviewboard Update (and migrate).
But would there be any way for the 'upgrade' logic of Reviewboard to post a
more useful error messa
On Sat, Jan 16, 2016 at 6:09 AM, Christian Hammond wrote:
> Hi Ben,
>
> You'll have a much easier time restoring from a backup. It's hard to say how
> far it went through the evolution process, and unfortunately today it
> doesn't keep track of how far it got and what it'd have to do to recover.
>
Hi Ben,
You'll have a much easier time restoring from a backup. It's hard to say
how far it went through the evolution process, and unfortunately today it
doesn't keep track of how far it got and what it'd have to do to recover.
You'd have a lot of trial and error to fix it manually. You can try i
On Fri, Jan 15, 2016 at 11:09 PM, Ben Cooksley wrote:
> On Fri, Jan 15, 2016 at 11:04 PM, Christian Hammond
> wrote:
>> Hi Ben,
>>
>> This is due to a mismatch between MySQL table types. The existing tables are
>> likely MyISAM, with MySQL now defaulting to InnoDB for new ones. You'll need
>> to
On Fri, Jan 15, 2016 at 11:04 PM, Christian Hammond
wrote:
> Hi Ben,
>
> This is due to a mismatch between MySQL table types. The existing tables are
> likely MyISAM, with MySQL now defaulting to InnoDB for new ones. You'll need
> to either migrate all the existing tables, or tell MySQL to use the
Hi Ben,
This is due to a mismatch between MySQL table types. The existing tables
are likely MyISAM, with MySQL now defaulting to InnoDB for new ones. You'll
need to either migrate all the existing tables, or tell MySQL to use the
existing type for new tables.
(It's a pretty terrible error, but un
Hi everyone,
While upgrading from Reviewboard 2.0.17 to 2.5.2 i've encountered a
few SQL errors.
Reviewboard itself appears to boot and run fine though, based on the
nature of the errors I suspect it's a case of index name collisions.
Output from the upgrade process is below:
(virtualenv)reviewb
13 matches
Mail list logo