--- title: "February, 2020" date: 2020-02-02T11:56:30+02:00 author: "Alan Orth" categories: ["Notes"] --- ## 2020-02-02 - Continue working on porting CGSpace's DSpace 5 code to DSpace 6.3 that I started yesterday - Sign up for an account with MaxMind so I can get the GeoLite2-City.mmdb database - I still need to wire up the API credentials and cron job into the Ansible infrastructure playbooks - Fix some minor issues in the config and XMLUI themes, like removing Atmire stuff - The code finally builds and runs with a fresh install - Now we don't specify the build environment because site modification are in `local.cfg`, so we just build like this: ``` $ schedtool -D -e ionice -c2 -n7 nice -n19 mvn -U -Dmirage2.on=true -Dmirage2.deps.included=false clean package ``` - And it seems that we need to enabled `pg_crypto` now (used for UUIDs): ``` $ psql -h localhost -U postgres dspace63 dspace63=# CREATE EXTENSION pgcrypto; CREATE EXTENSION pgcrypto; ``` - I tried importing a PostgreSQL snapshot from CGSpace and had errors due to missing Atmire database migrations - If I try to run `dspace database migrate` I get the IDs of the migrations that are missing - I delete them manually in psql: ``` dspace63=# DELETE FROM schema_version WHERE version IN ('5.0.2015.01.27', '5.6.2015.12.03.2', '5.6.2016.08.08', '5.0.2017.04.28', '5.0.2017.09.25', '5.8.2015.12.03.3'); ``` - Then I ran `dspace database migrate` and got an error: ``` $ ~/dspace63/bin/dspace database migrate Database URL: jdbc:postgresql://localhost:5432/dspace63?ApplicationName=dspaceCli Migrating database to latest version... (Check dspace logs for details) Migration exception: java.sql.SQLException: Flyway migration error occurred at org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:673) at org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:576) at org.dspace.storage.rdbms.DatabaseUtils.main(DatabaseUtils.java:221) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:229) at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:81) Caused by: org.flywaydb.core.internal.dbsupport.FlywaySqlScriptException: Migration V6.0_2015.03.07__DS-2701_Hibernate_migration.sql failed ----------------------------------------------------------------- SQL State : 2BP01 Error Code : 0 Message : ERROR: cannot drop table metadatavalue column resource_id because other objects depend on it Detail: view eperson_metadata depends on table metadatavalue column resource_id Hint: Use DROP ... CASCADE to drop the dependent objects too. Location : org/dspace/storage/rdbms/sqlmigration/postgres/V6.0_2015.03.07__DS-2701_Hibernate_migration.sql (/home/aorth/src/git/DSpace-6.3/file:/home/aorth/dspace63/lib/dspace-api-6.3.jar!/org/dspace/storage/rdbms/sqlmigration/postgres/V6.0_2015.03.07__DS-2701_Hibernate_migration.sql) Line : 391 Statement : ALTER TABLE metadatavalue DROP COLUMN IF EXISTS resource_id at org.flywaydb.core.internal.dbsupport.SqlScript.execute(SqlScript.java:117) at org.flywaydb.core.internal.resolver.sql.SqlMigrationExecutor.execute(SqlMigrationExecutor.java:71) at org.flywaydb.core.internal.command.DbMigrate.doMigrate(DbMigrate.java:352) at org.flywaydb.core.internal.command.DbMigrate.access$1100(DbMigrate.java:47) at org.flywaydb.core.internal.command.DbMigrate$4.doInTransaction(DbMigrate.java:308) at org.flywaydb.core.internal.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:72) at org.flywaydb.core.internal.command.DbMigrate.applyMigration(DbMigrate.java:305) at org.flywaydb.core.internal.command.DbMigrate.access$1000(DbMigrate.java:47) at org.flywaydb.core.internal.command.DbMigrate$2.doInTransaction(DbMigrate.java:230) at org.flywaydb.core.internal.command.DbMigrate$2.doInTransaction(DbMigrate.java:173) at org.flywaydb.core.internal.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:72) at org.flywaydb.core.internal.command.DbMigrate.migrate(DbMigrate.java:173) at org.flywaydb.core.Flyway$1.execute(Flyway.java:959) at org.flywaydb.core.Flyway$1.execute(Flyway.java:917) at org.flywaydb.core.Flyway.execute(Flyway.java:1373) at org.flywaydb.core.Flyway.migrate(Flyway.java:917) at org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:662) ... 8 more Caused by: org.postgresql.util.PSQLException: ERROR: cannot drop table metadatavalue column resource_id because other objects depend on it Detail: view eperson_metadata depends on table metadatavalue column resource_id Hint: Use DROP ... CASCADE to drop the dependent objects too. at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2422) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2167) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:306) at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:441) at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:365) at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:307) at org.postgresql.jdbc.PgStatement.executeCachedSql(PgStatement.java:293) at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:270) at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:266) at org.apache.commons.dbcp2.DelegatingStatement.execute(DelegatingStatement.java:291) at org.apache.commons.dbcp2.DelegatingStatement.execute(DelegatingStatement.java:291) at org.flywaydb.core.internal.dbsupport.JdbcTemplate.executeStatement(JdbcTemplate.java:238) at org.flywaydb.core.internal.dbsupport.SqlScript.execute(SqlScript.java:114) ... 24 more ``` - I think I might need to update the sequences first... nope - Perhaps it's due to some missing bitstream IDs and I need to run `dspace cleanup` on CGSpace and take a new PostgreSQL dump... nope - A thread on the dspace-tech mailing list regarding this migration noticed that his database had some views created that were using the `resource_id` column - Our database had the same issue, where the `eperson_metadata` view was created by something (Atmire module?) but has no references in the vanilla DSpace code, so I dropped it and tried the migration again: ``` dspace63=# DROP VIEW eperson_metadata; DROP VIEW ``` - After that the migration was successful and DSpace starts up successfully and begins indexing - xmlui, solr, jspui, and oai are working, but rest is not starting up (turns out rest was working, but it was redirecting to HTTPS... I wonder why, because it wasn't doing that on DSpace 5!) - I started diffing our themes against the Mirage 2 reference theme to capture the latest changes