Re: Review Board Ticket #4451: Deleting all files in a review request should remove the "Files" section

[David Trowbridge]

--
To reply, visit https://hellosplat.com/s/beanbag/tickets/4451/
--

New update by brennie
For Beanbag, Inc. > Review Board > Ticket #4451


Reply:

Fixed in release-2.5.x (a4af54f). This will ship in 2.5.8. Thanks!


Status:
- New
+ Fixed

-- 
You received this message because you are subscribed to the Google Groups 
"reviewboard-issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard-issues+unsubscr...@googlegroups.com.
To post to this group, send email to reviewboard-issues@googlegroups.com.
Visit this group at https://groups.google.com/group/reviewboard-issues.
For more options, visit https://groups.google.com/d/optout.

Re: Reviewboard upgrade failure

[Christian Hammond]

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 services (standalone and as part of a support contract) and can
usually get you in good shape within a few hours.

Christian


On Friday, October 28, 2016, 朱皓  wrote:

> Hi Daniel,
>
> This problem is caused by some bugs in the database upgrade script. You
> can fix it by dropping all duplicate columns and indexes. I have fixed it
> by keeping running this script (you may need to run it again and again, and
> make sure all these are dropped):
>
>
> ALTER TABLE accounts_reviewrequestvisit DROP COLUMN visibility;
> ALTER TABLE accounts_reviewrequestvisit DROP INDEX
> accounts_reviewrequestvisit_05ee5d21;
> ALTER TABLE attachments_fileattachment DROP COLUMN attachment_history_id;
> ALTER TABLE attachments_fileattachment DROP COLUMN attachment_revision;
> ALTER TABLE diffviewer_filediff DROP COLUMN raw_parent_diff_hash_id;
>
> ALTER TABLE diffviewer_filediff DROP COLUMN raw_diff_hash_id;
> ALTER TABLE diffviewer_filediff DROP INDEX diffviewer_filediff_4d02a56a;
> ALTER TABLE diffviewer_filediff DROP INDEX diffviewer_filediff_79f4fcf6;
> ALTER TABLE attachments_fileattachment DROP COLUMN attachment_revision;
>
> ALTER TABLE diffviewer_filediff DROP COLUMN raw_parent_diff_hash_id;
>
> On Tuesday, April 5, 2016 at 9:41:59 PM UTC+8, Daniel Laird wrote:
>>
>> 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 errors,
>> can be ignored unless upgrade fails.
>>
>> --  --
>> Creating tables ...
>> There are unapplied evolutions for accounts.
>> There are unapplied evolutions for attachments.
>> There are unapplied evolutions for diffviewer.
>> There are unapplied evolutions for reviews.
>> There are unapplied evolutions for webapi.
>> Project signature has changed - an evolution is required
>> Installing custom SQL ...
>> Installing indexes ...
>> Installed 0 object(s) from 0 fixture(s)
>> /usr/local/lib/python2.7/dist-packages/ReviewBoardPowerPack-
>> 1.4-py2.7.egg/rbpowerpack/scmtools/tfs.py:9: DeprecationWarning:
>> django.utils.simplejson is deprecated; use json instead.
>>
>> CommandError: Error applying evolution: (1060, "Duplicate column name
>> 'visibility'")
>> ...
>>
>> Any ideas on why I am getting this error or how I can get more debug to
>> help?
>> Much appreciated
>> Dan
>>
>> On Friday, 15 January 2016 19:44:43 UTC, Ben Cooksley wrote:
>>>
>>> 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.
>>> > You'd have a lot of trial and error to fix it manually. You can try
>>> it,
>>> > though.
>>> >
>>> > Basically, you'll need to dump the SQL that the evolutions want to
>>> apply,
>>> > and go through and hand-undo each thing it did until you get back to
>>> the
>>> > point of where it was. You'd definitely want to do a backup first,
>>> though.
>>>
>>> Unfortunately people had started using it already so this was the
>>> easiest approach :(
>>>
>>> Would it be possible to get a copy of a normally, safely upgraded
>>> schema so I can double check I haven't clobbered anything?
>>>
>>> The queries I ended up having to run to revert things to a state where
>>> the upgrade process would work was:
>>>
>>> 160115 19:34:12 2197763 Query   ALTER TABLE
>>> accounts_reviewrequestvisit DROP COLUMN visibility
>>> 160115 19:34:24 2197763 Query   DROP INDEX
>>> `accounts_reviewrequestvisit_05ee5d21` ON
>>> `accounts_reviewrequestvisit`
>>> 160115 19:34:45 2197763 Query   ALTER TABLE attachments_fileattachment
>>> DROP COLUMN attachment_revision, DROP COLUMN attachment_history_id
>>> 160115 19:34:58 2197763 Query   ALTER TABLE diffviewer_filediff DROP
>>> COLUMN raw_diff_hash_id, DROP COLUMN raw_parent_diff_hash_id
>>> 160115 19:36:18 2197763 Query   ALTER TABLE `reviews_group` DROP
>>> COLUMN `email_list_only`, DROP COLUMN is_default_group
>>> 160115 19:36:25 2197763 Query   DROP TABLE
>>> reviews_reviewrequest_file_attachment_histories
>>>
>>> Note that I observed that the Reviewboard process tries to reverse
>>> it's failed upgrade by doing a rollback. It is noted in the case of
>>> InnoDB that schema changes cannot be rolled back (see
>>> http://www.sitepoint.com/mysql-transaction-gotchas-good-parts/)
>>>
>>> >