Skip to content

2.0.0 Upgrade

Jump to bottom Edit New page
smutniak edited this page Jul 15, 2019 · 1 revision

Upgrade from any previous version to 1.8

Versions prior to Vireo 1.8 were based upon the DSpace architecture. With Vireo 1.8 the applications has been completely re-written using a different database and filesystem layout. Upgrading from this version of DSpace is difficult and will require a complete migration of your data from the old system into a new Vireo. There are a set of migration scripts in a separate project to handle this process. Good Luck.

Upgrade from 1.8 to 1.8.1

There is only one change between these versions of Vireo and it deals with how attachments are stored. In the previous version all attachments (pdf documents, supplemental files, etcs) were all lumped together into the attachment's directory. It was decided to change this so that the files are hashed into a series of sub directories. You will need to run the script below to hash the attachments.

hashAttachments.sh: #/bin/bash

baseDir=$1
echo "Hashing attachments in directory: $baseDir"

for i in `ls -1 $baseDir`; do
    echo $i

    mkdir -p $baseDir/${i:0:2}/${i:2:2}/${i:4:2}/${i:6:2}
    mv $baseDir/$i $baseDir/${i:0:2}/${i:2:2}/${i:4:2}/${i:6:2}/$i

done

Then run the script supplying the path to the attachments directory: $ hashAttachments /path/to/attachments/directory

Upgrade from 1.8.1 to 1.9

There are several database schema changes between previous versions and 1.9. You will need to upgrade your schema. The recommended configuration is for production instances of Vireo to use jpa.ddl = validate. This will ensure that a rogue process can not modify the database schema. However, when upgrading you will need to modify the ddl (Data Definition Language) setting at least once, to: jpa.ddl = update. Then bring up the application at least once. When the application starts up the schema will be updated to reflect the changes. You may then immediately bring the application back down and restore the validate setting.

Upgrade from 1.9.x to 2.0

The new dynamic committee member role system requires a migration step to preserve the roles of existing committee members. Run the following command before running the the newer Vireo:

-- Create the new dynamic committee member roles table
create table committee_member_roles (
    JpaCommitteeMemberImpl_id int8 not null,
    roles varchar(255),
    roles_ORDER int4 not null,
    primary key (JpaCommitteeMemberImpl_id, roles_ORDER)
);

-- Add constraints
alter table committee_member_roles 
    add constraint FK205EE65A9A0CF993 
    foreign key (JpaCommitteeMemberImpl_id) 
    references committee_member;

-- Migrate the Chair role
insert into committee_member_roles
    select id, 'Chair', 0 
    from committee_member
    where chair is true;

-- Drop the old column
alter table committee_member
    drop column chair;

After running the schema updates above there are still additional schema changes that are handled by the application. Change the your jpa.ddl setting to update when you bring up the upgraded Vireo 2.0 for the first tame. Then after that change the jpa.ddl setting back to validate.

Upgrade from 2.0 to 2.0.1

Unfortunately there is a bug in 2.0 that prevents submissions from being deleted if they are referenced by saved filters. This is because of the foreign key constraints. This bug has been fixed, but requires significant changes to the search filter tables. When you upgrade these tables will need to be dropped, and then created. A big side effect of this is that all saved filters will be lost between the upgrade. In addition to the safe filters issue, duplicate system templates were created with "_" instead of spaces. This would result in two email templates: "SYSTEM Initial Submission" and "SYSTEM_Initial_Submission". Run the following SQL to correct for these issues:

-- Drop the search filter tables, they will be recreated without foreign key constraints.
DROP TABLE IF EXISTS search_filter_colleges;
DROP TABLE IF EXISTS search_filter_degrees;
DROP TABLE IF EXISTS search_filter_departments;
DROP TABLE IF EXISTS search_filter_programs;
DROP TABLE IF EXISTS search_filter_documenttypes;
DROP TABLE IF EXISTS search_filter_embargo_type;
DROP TABLE IF EXISTS search_filter_excluded_actionlogs;
DROP TABLE IF EXISTS search_filter_excluded_submissions;
DROP TABLE IF EXISTS search_filter_included_actionlogs;
DROP TABLE IF EXISTS search_filter_included_submissions;
DROP TABLE IF EXISTS search_filter_majors;
DROP TABLE IF EXISTS search_filter_person;
DROP TABLE IF EXISTS search_filter_semesters;
DROP TABLE IF EXISTS search_filter_states;
DROP TABLE IF EXISTS search_filter_text;
DROP TABLE IF EXISTS search_filter_assignees;
DROP TABLE IF EXISTS search_filter_embargos;
DROP TABLE IF EXISTS search_filter;

-- Drop duplicate email templates
DELETE FROM email_template WHERE name = 'SYSTEM_Advisor_Review_Request';
DELETE FROM email_template WHERE name = 'SYSTEM_Initial_Submission';

After running the drop table statements above, re-create the search filter tables by changing your jpa.ddl setting to update when you bring up the upgraded Vireo 2.0 for the first tame. Then after that change the jpa.ddl setting back to validate.

Upgrade from 2.0.x to 3.0.3

  • Make sure you are upgrading the play framework to 1.3.0 since Vireo 3.0.3 is not compatible with play frameworks 1.2.x or 2.x. You can find our fork's release of play framework 1.3.0 here OR you can get the official one from here
  • The upgrade process from 2.0.x to 3.0.3 is a little broken since not all the schema changes are taken care of by JPA when vireo is started with jpa.ddl set to update because of a bug with Hibernate v4.2 that is used in Play 1.3.0. There is a 2-step process to upgrade the database from Vireo 2.0.x to 3.0.3:
    1. With Vireo 2.0.x stopped: run the schema upgrade located in conf/sql/(postgresql | mysql)/upgrade/vireo_2081_300_updgrade-schema.sql
    2. With Vireo 3.0.3 started (with jpa.ddl set to update): run the data upgrade located in conf/sql/(postgresql | mysql)/upgrade/vireo_2081_300_updgrade-data.sql
  1. Stop Vireo 2.0.x
  2. Run the DB schema upgrade mentioned in the note above
  3. Unzip the new release's source code in a new directory (or use git to bring your server's Vireo directory up to date with TAG v3.0.3)
  4. Modify application.conf to match your previous settings
  • Please note that mail.from and mail.replyto options are no longer there (they are configured in the web UI now) and that there are a few new configuration options compared to Vireo 2.x
  1. Make sure your attachments.path index.path and deposits.path are accessible by Vireo
  2. Remove old pre-compiled files and dependencies:
  • rm -rf tmp/ modules/ lib/
  1. Re-sync the dependencies using the new play framework and vireo code
  • // Download library dependencies
  • play dependencies --sync --clearcache --%test
  1. Make sure that jpa.ddl is set to update in application.conf (you can change it to whatever you want after the last upgrade step)
  2. Start Vireo
  3. Run the DB data upgrade mentioned in the note above.
  4. In a browser: clear your browser cookies, log in to Vireo3, go to Admin->System links and delete & re-build the index.
  5. LASTLY: Verify that all embargoes have been successfully migrated from Vireo2 to Vireo3, then run the sql cleanup script located in conf/sql/(postgresql | mysql)/upgrade/vireo_2081_300_updgrade-cleanup.sql
Add a custom footer
Clone this wiki locally