Top Menu

Jump to content
Home
    Modules
      • Projects
      • Activity
      • Work packages
      • Gantt charts
      • Calendars
      • Team planners
      • Boards
      • News
    • Getting started
    • Introduction video
      Welcome to OpenProject Community
      Get a quick overview of project management and team collaboration with OpenProject. You can restart this video from the help menu.

    • Help and support
    • Upgrade to Enterprise edition
    • User guides
    • Videos
    • Shortcuts
    • Community forum
    • Enterprise support

    • Additional resources
    • Data privacy and security policy
    • Digital accessibility (DE)
    • OpenProject website
    • Security alerts / Newsletter
    • OpenProject blog
    • Release notes
    • Report a bug
    • Development roadmap
    • Add and edit translations
    • API documentation
  • Sign in
      Forgot your password?

      or sign in with your existing account

      Google

Side Menu

  • Overview
  • Activity
    Activity
  • Roadmap
  • Work packages
    Work packages
  • Gantt charts
    Gantt charts
  • Calendars
    Calendars
  • Team planners
    Team planners
  • Boards
    Boards
  • News
  • Forums

Content

General discussion
  1. OpenProject
  2. Forums
  3. General discussion
  4. Possible problems ahead, migration error

Possible problems ahead, migration error

Added by Alejandro Nadal over 3 years ago

Hello everyone

I am using Openproject version 11.3.5, running on Debian 10.

I had to update from Openproject 10 to Openproject 11. I did a backup, installed Openproject 11 and tried to restore. However, a migration kept failing, to be precise, this one:

https://github.com/opf/openproject/blob/dev/db/migrate/20181112125034_create_doorkeeper_tables.rb

This migration kept failing, so I deleted it and added manually the databases:

CREATE TABLE oauth_access_grants(
    id bigint, 
    resource_owner_id bigint not null,
    application_id bigint not null,
    token varchar(255) not null,
    expires_in bigint not null,
    redirect_uri text not null,
    created_at timestamp not null,
    revoked_at timestamp,
    scopes varchar(255)
);

ALTER TABLE oauth_access_grants ADD CONSTRAINT id_pk PRIMARY KEY(id);
ALTER TABLE oauth_access_grants ADD CONSTRAINT application_id_fk FOREIGN KEY (application_id) REFERENCES oauth_applications(id);

CREATE TABLE oauth_access_tokens(
    id bigint,
    resource_owner_id bigint not null,
    application_id bigint not null,
    refresh_token varchar(255),
    expires_in bigint,
    revoked_at timestamp,
    created_at timestamp not null,
    scopes varchar(255),
    previous_refresh_token varchar(255) not null default '',
    code_challenge varchar(255),
    code_challenge_method varchar(255),
);

ALTER TABLE oauth_access_tokens ADD CONSTRAINT tokens_id_pk PRIMARY KEY(id);
ALTER TABLE oauth_access_tokens ADD CONSTRAINT oauth_access_tokens_fk FOREIGN KEY(application_id) REFERENCES oauth_applications(id);

Will this cause me problems ahead?
Also, another little red flag that I am seeing:

If I try to run "openproject configure" I am getting this:

"Could not find nio4r-2.5.6 in any of the sources, Run bundle install to install missing gems"

I am wondering if I should try to reinstall everything, but first I wanted to ask here about this and hear your opinions on my manual adding of these tables and on my problem with openproject configure.

Thanks in advance!
Alejandro


Replies (1)

RE: Possible problems ahead, migration error - Added by Wieland Lindenthal over 3 years ago

Hi Alejandro,

Thanks for using OpenProject and all your efforts to make it work for you.

Just for clarification: You took a backup of OpenProject 10 and want to restore it in OpenProject 11? To me this sounds like the order is messed up. So if you have OpenProject 10 running (from which you created the Backup) you simple need to install the latest OpenProject and upgrade. On Debian that looks like this

sudo apt-get update
sudo apt-get install --only-upgrade openproject
sudo openproject configure

There should not be any need for restoring backups.
And no, you should not need to write the migration yourself in SQL. And no, I cannot tell if your SQL does exactly the same as our migration. Please keep in mind that all performed migrations are also saved with their timestamps in the DB table schema_migrations. If you really want to pull through with your approach (which I'd like to discourage) you will also need to insert that migration into that table.

Unfortunately I can't tell why you are having issues with `nio4r-2.5.6`. For me it smells like the upgrade did not properly happen (update ruby version, gems, etc.).

Regards,

Wieland

  • (1 - 1/1)
Loading...