mirror of
https://github.com/alanorth/cgspace-notes.git
synced 2024-11-19 21:25:01 +01:00
168 lines
10 KiB
Markdown
168 lines
10 KiB
Markdown
---
|
|
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
|
|
|
|
<!--more-->
|
|
|
|
- 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, rest, and oai are working (rest was redirecting to HTTPS, so I set the Tomcat connector to `secure="true"` and it fixed it on localhost, but caused other issues so I disabled it for now)
|
|
- I started diffing our themes against the Mirage 2 reference theme to capture the latest changes
|
|
|
|
## 2020-02-03
|
|
|
|
- Update DSpace mimetype fallback images from [KDE Breeze Icons](https://github.com/KDE/breeze-icons) project
|
|
- Our icons are four years old (see [my bitstream icons demo](https://alanorth.github.io/dspace-bitstream-icons/))
|
|
- Issues remaining in the DSpace 6 port of our CGSpace 5.x code:
|
|
- [ ] Community and collection pages only show one recent submission (seems that there is only one item in Solr?)
|
|
- [ ] Community and collection pages have tons of "Browse" buttons that we need to remove
|
|
- [ ] Order of navigation elements in right side bar ("My Account" etc, compare to DSpace Test)
|
|
- [ ] Home page trail says "CGSpace Home" instead of "CGSpace Home / Community List" (see DSpace Test)
|
|
- There are lots of errors in the DSpace log, which might explain some of the issues with recent submissions / Solr:
|
|
|
|
```
|
|
2020-02-03 10:27:14,485 ERROR org.dspace.browse.ItemCountDAOSolr @ caught exception:
|
|
org.dspace.discovery.SearchServiceException: Invalid UUID string: 1
|
|
2020-02-03 13:20:20,475 ERROR org.dspace.app.xmlui.aspect.discovery.AbstractRecentSubmissionTransformer @ Caught SearchServiceException while retrieving recent submission for: home page
|
|
org.dspace.discovery.SearchServiceException: Invalid UUID string: 111210
|
|
```
|
|
|
|
- If I look in Solr's search core I do actually see items with integers for their resource ID, which I think are all supposed to be UUIDs now...
|
|
- I dropped all the documents in the search core:
|
|
|
|
```
|
|
$ http --print b 'http://localhost:8080/solr/search/update?stream.body=<delete><query>*:*</query></delete>&commit=true'
|
|
```
|
|
|
|
- Still didn't work, so I'm going to try a clean database import and migration:
|
|
|
|
```
|
|
$ createdb -h localhost -U postgres -O dspacetest --encoding=UNICODE dspace63
|
|
$ psql -h localhost -U postgres -c 'alter user dspacetest superuser;'
|
|
$ pg_restore -h localhost -U postgres -d dspace63 -O --role=dspacetest -h localhost dspace_2020-01-27.backup
|
|
$ psql -h localhost -U postgres -c 'alter user dspacetest nosuperuser;'
|
|
$ psql -h localhost -U postgres dspace63
|
|
dspace63=# CREATE EXTENSION pgcrypto;
|
|
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');
|
|
dspace63=# DROP VIEW eperson_metadata;
|
|
dspace63=# \q
|
|
$ psql -h localhost -U postgres -f ~/src/git/DSpace/dspace/etc/postgres/update-sequences.sql dspace63
|
|
$ ~/dspace63/bin/dspace database migrate
|
|
```
|
|
|
|
- I notice that the indexing doesn't work correctly if I start it manually with `dspace index-discovery -b` (search.resourceid becomes an integer!)
|
|
- If I induce an indexing by touching `dspace/solr/search/conf/reindex.flag` the search.resourceid are all UUIDs...
|
|
- Speaking of database stuff, there was a performance-related update for the [indexes that we used in DSpace 5](https://github.com/DSpace/DSpace/pull/1791/)
|
|
- We might want to [apply it in DSpace 6](https://github.com/DSpace/DSpace/pull/1792), as it was never merged to 6.x, but it helped with the performance of `/submissions` in XMLUI for us in [2018-03]({{< relref path="2018-03.md" >}})
|
|
|
|
<!-- vim: set sw=2 ts=2: -->
|