Re: Database Upgrade Error

[Chris Eagan]

I found another discussion about this issue on this forum [forum post 
] and sure 
enough, my database dump shows that the tables are using MyISAM. I 
converted the database dump to specify InnoDB instead using the following 
command and did a new import followed by an rb-site upgrade.

sed 's/) ENGINE=MyISAM/) ENGINE=InnoDB/g' reviewboard.sql > reviewboard2.sql


This took a really long time to import, so be sure you get it right before 
you try the import. I added wait_timeout = 31536000 to the [server] section 
of /etc/my.cnf.d/server.cnf and restarted MariaDB to ensure that the import 
had time to complete. Also, make sure you have enough free disk space to 
complete the import.

Ultimately, this appears to have worked and given us successful migration 
of the database. Hopefully, this thread helps someone else. :)

On Friday, March 24, 2017 at 9:16:05 AM UTC-4, Chris Eagan wrote:
>
> When attempting to perform an rb-site upgrade from version 2.0.18 to 
> 2.5.9, I get the following output, ending in an error. If I continue, 
> further table creation issues occur and the result is a corrupted database. 
> I do have a backup of the database, which I have been using to restore and 
> test the migrations.
>
> Rebuilding directory structure
> Upgrading site settings_local.py
> Updating database. This may take a while.
>
>
> The log output below, including warnings and errors,
> can be ignored unless upgrade fails.
>
>
> --  --
> Creating tables ...
> Creating table attachments_fileattachmenthistory
> Creating table diffviewer_rawfilediffdata
> Creating table notifications_webhooktarget_repositories
>
>
> [!] There was an error synchronizing the database. Make sure the
> database is created and has the appropriate permissions, and then
> continue.
> [!] Details: (1005, "Can't create table 'reviewboard.#sql-64a_3'
> (errno: 150)")
>
>
> Press Enter to continue
>
>
> The permissions are correct and I even tried running the command by 
> specifying the root user of the database and their password. Some Googling 
> makes this seem like it could be due to Foreign key issues where the new 
> databases are being created out of order. I am wondering if disabling 
> Foreign Key Checks globally, performing the migration, and then enabling 
> the checks again would help and if it would be safe with respect to 
> ReviewBoard itself.
>
> Something like:
>
> SET GLOBAL FOREIGN_KEY_CHECKS=0;
>
>
> Run the rb-site upgrade.
>
>  
>
> SET GLOBAL FOREIGN_KEY_CHECKS=1;
>
>
> Thoughts? Recommendations?
>

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database Upgrade Error

[Chris Eagan]

I found another discussion about this issue on this forum [forum post 
] and sure 
enough, my database dump shows that the tables are using MyISAM. I 
converted the database dump to specify InnoDB instead using the following 
command and did a new import followed by an rb-site upgrade.

sed 's/) ENGINE=MyISAM/) ENGINE=InnoDB/g' reviewboard.sql > reviewboard2.sql


This took a really long time to import, so be sure you get it right before 
you try the import. I added wait_timeout = 31536000 to the [server] section 
of /etc/my.cnf.d/server.cnf and restarted MariaDB to ensure that the import 
had time to complete. Also, make sure you have enough free disk space to 
complete the import.

Ultimately, this appears to have worked and given us successful migration 
of the database. Hopefully, this thread helps someone else. :)

On Friday, March 24, 2017 at 9:16:05 AM UTC-4, Chris Eagan wrote:
>
> When attempting to perform an rb-site upgrade from version 2.0.18 to 
> 2.5.9, I get the following output, ending in an error. If I continue, 
> further table creation issues occur and the result is a corrupted database. 
> I do have a backup of the database, which I have been using to restore and 
> test the migrations.
>
> Rebuilding directory structure
> Upgrading site settings_local.py
> Updating database. This may take a while.
>
>
> The log output below, including warnings and errors,
> can be ignored unless upgrade fails.
>
>
> --  --
> Creating tables ...
> Creating table attachments_fileattachmenthistory
> Creating table diffviewer_rawfilediffdata
> Creating table notifications_webhooktarget_repositories
>
>
> [!] There was an error synchronizing the database. Make sure the
> database is created and has the appropriate permissions, and then
> continue.
> [!] Details: (1005, "Can't create table 'reviewboard.#sql-64a_3'
> (errno: 150)")
>
>
> Press Enter to continue
>
>
> The permissions are correct and I even tried running the command by 
> specifying the root user of the database and their password. Some Googling 
> makes this seem like it could be due to Foreign key issues where the new 
> databases are being created out of order. I am wondering if disabling 
> Foreign Key Checks globally, performing the migration, and then enabling 
> the checks again would help and if it would be safe with respect to 
> ReviewBoard itself.
>
> Something like:
>
> SET GLOBAL FOREIGN_KEY_CHECKS=0;
>
>
> Run the rb-site upgrade.
>
>  
>
> SET GLOBAL FOREIGN_KEY_CHECKS=1;
>
>
> Thoughts? Recommendations?
>

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PL SQL support on review board

[David Trowbridge]

Looking at that package, I believe that just installing it and restarting
your web server will work.

-David

On Fri, Mar 24, 2017 at 9:06 AM Satya B N  wrote:

> Sorry for the late reply. Thanks for the mentioning the word "Pygments".
>
> I googled and got the pygments for Oracle PL/SQL.
>
> https://github.com/felipebz/oraclesql-pygments-lexer
>
> Is it possible to use third party Pygments and Review Board will be able
> to highlight KEYWORDS, syntax etc?
>
>
> Regards,
> Satya
>
>
> On Tuesday, February 28, 2017 at 8:47:53 AM UTC+5:30, David Trowbridge
> wrote:
>
> Any and all text files are reviewable. It looks like Pygments doesn't have
> specific support for PL/SQL though, so you won't see syntax highlighting
> other than any generic SQL highlighting.
>
> -David
>
> On Thu, Feb 23, 2017 at 7:34 PM Satya B N  wrote:
>
> HI David,
>
>
> On Wednesday, February 22, 2017 at 1:29:37 PM UTC+5:30, David Trowbridge
> wrote:
>
> Are you referring to running Review Board using an oracle SQL server for
> deployment, or are you looking to review PL/SQL code?
>
>
> the later. Just review PL/SQL code.
>
> Regards,
> Satya
>
> -David
>
> On Tue, Feb 21, 2017 at 11:58 PM Satya B N  wrote:
>
> Hi,
>
> Does Review Board support PL/SQL? Does it do syntax highlighting?
>
> I was about to suggest review board to my friend but not sure whether it
> supports PL/SQL ?
>
>
> I use it for c++, it works great!
>
> --
> Supercharge your Review Board with Power Pack:
> https://www.reviewboard.org/powerpack/
> Want us to host Review Board for you? Check out RBCommons:
> https://rbcommons.com/
> Happy user? Let us know! https://www.reviewboard.org/users/
> ---
> You received this message because you are subscribed to the Google Groups
> "reviewboard" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to reviewboard...@googlegroups.com.
>
>
> For more options, visit https://groups.google.com/d/optout.
>
> --
> Supercharge your Review Board with Power Pack:
> https://www.reviewboard.org/powerpack/
> Want us to host Review Board for you? Check out RBCommons:
> https://rbcommons.com/
> Happy user? Let us know! https://www.reviewboard.org/users/
> ---
> You received this message because you are subscribed to the Google Groups
> "reviewboard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to reviewboard...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> Supercharge your Review Board with Power Pack:
> https://www.reviewboard.org/powerpack/
> Want us to host Review Board for you? Check out RBCommons:
> https://rbcommons.com/
> Happy user? Let us know! https://www.reviewboard.org/users/
> ---
> You received this message because you are subscribed to the Google Groups
> "reviewboard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to reviewboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PL SQL support on review board

[Satya B N]

Sorry for the late reply. Thanks for the mentioning the word "Pygments". 

I googled and got the pygments for Oracle PL/SQL.

https://github.com/felipebz/oraclesql-pygments-lexer

Is it possible to use third party Pygments and Review Board will be able to 
highlight KEYWORDS, syntax etc?


Regards,
Satya

On Tuesday, February 28, 2017 at 8:47:53 AM UTC+5:30, David Trowbridge 
wrote:
>
> Any and all text files are reviewable. It looks like Pygments doesn't have 
> specific support for PL/SQL though, so you won't see syntax highlighting 
> other than any generic SQL highlighting.
>
> -David
> On Thu, Feb 23, 2017 at 7:34 PM Satya B N > 
> wrote:
>
>> HI David,
>>
>>
>> On Wednesday, February 22, 2017 at 1:29:37 PM UTC+5:30, David Trowbridge 
>> wrote:
>>>
>>> Are you referring to running Review Board using an oracle SQL server for 
>>> deployment, or are you looking to review PL/SQL code?
>>>
>>>
>> the later. Just review PL/SQL code.
>>
>> Regards,
>> Satya
>>
>> -David
>>>
>> On Tue, Feb 21, 2017 at 11:58 PM Satya B N  wrote:
>>>
>> Hi,

 Does Review Board support PL/SQL? Does it do syntax highlighting? 

 I was about to suggest review board to my friend but not sure whether 
 it supports PL/SQL ?


 I use it for c++, it works great!

 -- 
 Supercharge your Review Board with Power Pack: 
 https://www.reviewboard.org/powerpack/
 Want us to host Review Board for you? Check out RBCommons: 
 https://rbcommons.com/
 Happy user? Let us know! https://www.reviewboard.org/users/
 --- 
 You received this message because you are subscribed to the Google 
 Groups "reviewboard" group.

>>> To unsubscribe from this group and stop receiving emails from it, send 
 an email to reviewboard...@googlegroups.com.
>>>
>>>
 For more options, visit https://groups.google.com/d/optout.

>>> -- 
>> Supercharge your Review Board with Power Pack: 
>> https://www.reviewboard.org/powerpack/
>> Want us to host Review Board for you? Check out RBCommons: 
>> https://rbcommons.com/
>> Happy user? Let us know! https://www.reviewboard.org/users/
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "reviewboard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to reviewboard...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database Upgrade Error

[Chris Eagan]

I went ahead and tested this and the upgrade finished without errors. I was 
able to login to Review Board but attempts to access existing review 
requests resulted in the following error:

IntegrityError: (1452, 'Cannot add or update a child row: a foreign key 
constraint fails 
(`reviewboard`.`reviews_reviewrequest_file_attachment_histories`, 
CONSTRAINT `reviewrequest_id_refs_id_fe050f91` FOREIGN KEY 
(`reviewrequest_id`) REFERENCES `reviews_reviewrequest` (`id`))')


This makes sense since there were clearly Foreign Key issues previously 
during the upgrade so it looks like my workaround doesn't work.

This installation is on CentOS 7 and Review Board was installed with EPEL 
packages. The installation appears to be using acceptable versions of all 
the dependencies and is running on Python 2.7.5.

It is worth trying to perform the upgrades via older releases of Review 
Board between the two releases I am trying to install?

On Friday, March 24, 2017 at 9:16:05 AM UTC-4, Chris Eagan wrote:
>
> When attempting to perform an rb-site upgrade from version 2.0.18 to 
> 2.5.9, I get the following output, ending in an error. If I continue, 
> further table creation issues occur and the result is a corrupted database. 
> I do have a backup of the database, which I have been using to restore and 
> test the migrations.
>
> Rebuilding directory structure
> Upgrading site settings_local.py
> Updating database. This may take a while.
>
>
> The log output below, including warnings and errors,
> can be ignored unless upgrade fails.
>
>
> --  --
> Creating tables ...
> Creating table attachments_fileattachmenthistory
> Creating table diffviewer_rawfilediffdata
> Creating table notifications_webhooktarget_repositories
>
>
> [!] There was an error synchronizing the database. Make sure the
> database is created and has the appropriate permissions, and then
> continue.
> [!] Details: (1005, "Can't create table 'reviewboard.#sql-64a_3'
> (errno: 150)")
>
>
> Press Enter to continue
>
>
> The permissions are correct and I even tried running the command by 
> specifying the root user of the database and their password. Some Googling 
> makes this seem like it could be due to Foreign key issues where the new 
> databases are being created out of order. I am wondering if disabling 
> Foreign Key Checks globally, performing the migration, and then enabling 
> the checks again would help and if it would be safe with respect to 
> ReviewBoard itself.
>
> Something like:
>
> SET GLOBAL FOREIGN_KEY_CHECKS=0;
>
>
> Run the rb-site upgrade.
>
>  
>
> SET GLOBAL FOREIGN_KEY_CHECKS=1;
>
>
> Thoughts? Recommendations?
>

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Database Upgrade Error

[Chris Eagan]

When attempting to perform an rb-site upgrade from version 2.0.18 to 2.5.9, 
I get the following output, ending in an error. If I continue, further 
table creation issues occur and the result is a corrupted database. I do 
have a backup of the database, which I have been using to restore and test 
the migrations.

Rebuilding directory structure
Upgrading site settings_local.py
Updating database. This may take a while.


The log output below, including warnings and errors,
can be ignored unless upgrade fails.


--  --
Creating tables ...
Creating table attachments_fileattachmenthistory
Creating table diffviewer_rawfilediffdata
Creating table notifications_webhooktarget_repositories


[!] There was an error synchronizing the database. Make sure the
database is created and has the appropriate permissions, and then
continue.
[!] Details: (1005, "Can't create table 'reviewboard.#sql-64a_3'
(errno: 150)")


Press Enter to continue


The permissions are correct and I even tried running the command by 
specifying the root user of the database and their password. Some Googling 
makes this seem like it could be due to Foreign key issues where the new 
databases are being created out of order. I am wondering if disabling 
Foreign Key Checks globally, performing the migration, and then enabling 
the checks again would help and if it would be safe with respect to 
ReviewBoard itself.

Something like:

SET GLOBAL FOREIGN_KEY_CHECKS=0;


Run the rb-site upgrade.

 

SET GLOBAL FOREIGN_KEY_CHECKS=1;


Thoughts? Recommendations?

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Subversion workflow help

[Ivan Žitko]

Hi,

I can see this is old post, but this post is most similar to my problem, so 
I will just join this discussion. I hope it's ok.

In my company, we use SVN, and we installed RB in order to improve quality 
of our code. 
I tried to use RB with pre-commit review workflow but it seems that it 
don't fit our needs. Our commits includes small chunks of code, and we 
commit very often. Also, very often commits use same files (eg. we have RIA 
Service Domain class with a lot of business logic in it). Because of that, 
with pre-commit workflow if developer create review which includes file1 
and he have other change in same file1 waiting to be implemented, he cannot 
continue working until first review process is over. If he continues before 
that happens, next review will include first change and second change, in 
same review request. The reviewer have to spend too much time to filter 
only change 2. And this is simplified version of that problem.

So, we decided to try with post-commit workflow, and there is next problem: 
We cannot iterate on same original change. If something have to be fixed, 
developer only have option to mark review as "Fixed" and if he wants to 
update original change in that review that is not an option. Instead, he 
have to open new review requests to iterate same change, but then we have 
all same problems Willy had.

Can You give me solution for our problems, no matter if it is pre or post 
commit?

Thanks a lot.



On Monday, September 28, 2015 at 9:20:46 PM UTC+2, Christian Hammond wrote:

> Hi Willie,
>
> The expectation is that if you're doing a post-commit workflow like this, 
> where you commit and then post for review, you're not going to reuse the 
> same review request.
>
> A review request is intended to handle the review of a single change and 
> all is iterations. When you post something for review, you create a review 
> request, get feedback, and then you're expected to iterate on *that* change 
> (not a new one), containing both the original code and the fixes made, so 
> that reviewers can see the whole complete state of your change.
>
> What you're currently doing is posting one change for review (a change 
> that's already committed), and then creating new changes that don't in any 
> way contain the original change as new commits, but wanting both to appear 
> in a review request. This ends up causing the following issues:
>
> 1) You lose out on the ability to do interdiffs (which are used to see and 
> comment on the differences between any two iterations of your change).
>
> 2) It's letting code that may have errors go into the codebase, 
> potentially impacting others unnecessarily, rather than committing only 
> fully-reviewed, safe code.
>
> 3) It makes it far harder to track cohesive changes when going back 
> through the codebase or review request history.
>
> What we recommend is a pre-commit model. In this model, you would change 
> your steps to:
>
> 1) Modify code, but don't commit.
> 2) Developer runs `rbt post`
> 3) Reviews happen, and the developer gets feedback.
> 4) Developer modifies the code in their tree. Still doesn't commit.
> 5) Developer runs `rbt post -r ` to update the change.
> 6) Rinse and repeat until the change is ready to commit.
>
> This will give you all the intended power of our review requests and 
> interdiffs, and will prevent your repository from containing half-baked 
> changes that may end up blocking other developers.
>
> Christian
>
> -- 
> Christian Hammond - chi...@chipx86.com 
> Review Board - https://www.reviewboard.org
> Beanbag, Inc. - https://www.beanbaginc.com
>
> On Mon, Sep 28, 2015 at 6:42 AM, Willie Scholtz  > wrote:
>
>> Hi There
>>
>> I finally managed to install and get reviewboard running, 
>>
>> Our team has about 9 developers who all use windows machines, we have a 
>> Subversion repository.
>>
>> I helped everyone setting up "rbt" and currently our workflow 
>> (post-commit) works like this:
>>
>>
>>- commit code to */trunk*
>>- developer runs *rbt post REV_NUMBER -> creates review #*
>>- review group receives mail and starts review
>>- finds issues, and creates review
>>- submitter receives mail and fixes code, commit to trunk
>>- developer runs rbt post -r  REV_NUMBER
>>- cycle continues...
>>
>>
>> This works awesome, except that I have run into two problems, but this 
>> may be a config issue, or something we are doing wrong.
>>
>>
>>- When submitting via "rbt post", the "Change" field does not get 
>>populated?
>>
>>
>>- this works when going through the web-front end: 
>>   1. 
>>
>>Change: 9947
>>
>> 
>>
>>
>>
>>-  when updating requests via "rbt post -r  REV_NUMBER", 
>>the diff slider behaves very strange
>>   - for instance when sliding between ORIG, and subsequent updates, 
>>   it detects that in updates, origin files have been deleted.
>>   - ex:
>>  - commit 1 has file 1, 2 and 3
>>