dspace 7 upgrade database errors

[Joyner Library]

My library database has a few ignored tables running the database info command. Running the 'dspace database migrate ignored' command gives an error too. I think the resource_id was moved back in version 5 or 6 and that is just throwing everything off.

Going from dspace 6.3 to 7

OS: Windows 2012

Java: openjdk 11 2018-09-25

Maven: 3.6.3

Ant: 1.10.9

Postgres: 13.4

Solr: 8.9

Tomcat: 9.0.52

-------------------------------------------------------------------------------

-- grant read/write/delete/add/remove permission on all Bitstreams of Bundle --

-- ORIGINAL to reviewers                                                     --

-------------------------------------------------------------------------------

INSERT INTO resourcepolicy

  (policy_id, resource_type_id, action_id, rptype, eperson_id, resource_id)

  SELECT

    nextval('resourcepolicy_seq') AS policy_id,

    '0' AS resource_type_id,

    '4' AS action_id,

    'TYPE_WORKFLOW' AS rptype,

    wfi.owner AS eperson_id,

    b2b.bitstream_id AS dspace_object

  FROM workflowitem AS wfi

  JOIN item2bundle AS i2b

  ON i2b.item_id = wfi.item_id

  JOIN bundle2bitstream AS b2b

  ON b2b.bundle_id = i2b.bundle_id

  JOIN metadatavalue AS mv

  ON mv.resource_id = i2b.bundle_id

  JOIN metadatafieldregistry as mfr

  ON mv.metadata_field_id = mfr.metadata_field_id

  JOIN metadataschemaregistry as msr

  ON mfr.metadata_schema_id = msr.metadata_schema_id

  WHERE

    msr.namespace = 'http://dublincore.org/documents/dcmi-terms/'

    AND mfr.element = 'title'

    AND mfr.qualifier IS NULL

    AND mv.text_value = 'ORIGINAL'

    AND wfi.owner IS NOT NULL

    AND (wfi.state = 2 OR wfi.state = 4 OR wfi.state = 6)

    AND NOT EXISTS(

        SELECT 1 FROM resourcepolicy WHERE resource_type_id = 0 AND action_id = 4 AND resourcepolicy.eperson_id = owner AND resourcepolicy.resource_id = b2b.bitstream_id

    );

]; nested exception is org.postgresql.util.PSQLException: ERROR: operator does not exist: integer = uuid

  Hint: No operator matches the given name and argument types. You might need to add explicit type casts.

  Position: 767

        at org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.doTranslate(SQLStateSQLExceptionTranslator.java:101)

        at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:72)

        at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:81)

        at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:81)

        at org.springframework.jdbc.core.JdbcTemplate.translateException(JdbcTemplate.java:1443)

        at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:388)

        at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:418)

        at org.dspace.storage.rdbms.DatabaseUtils.executeSql(DatabaseUtils.java:1092)

        ... 34 more

Caused by: org.postgresql.util.PSQLException: ERROR: operator does not exist: integer = uuid

  Hint: No operator matches the given name and argument types. You might need to add explicit type casts.

  Position: 767

        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2505)

        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2241)

        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:310)

        at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:447)

        at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:368)

        at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:309)

        at org.postgresql.jdbc.PgStatement.executeCachedSql(PgStatement.java:295)

        at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:272)

        at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:267)

        at org.apache.commons.dbcp2.DelegatingStatement.execute(DelegatingStatement.java:194)

        at org.apache.commons.dbcp2.DelegatingStatement.execute(DelegatingStatement.java:194)

        at org.springframework.jdbc.core.JdbcTemplate$1ExecuteStatementCallback.doInStatement(JdbcTemplate.java:409)

        at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:376)

[Tim Donohue]

Hi,

Do you happen to know if you were using the Configurable/XML Workflow in DSpace 6.x?  Or did you use the older "traditional" three-step workflow approval process?

The reason I ask is that this failing migration seems like it is specific to the older three-step workflow approval process...so it's a bit odd that it's trying to run for you (as it should be an unnecessary migration).  But, if you could give us more information, maybe we can debug what is going on better.

Tim

[Joyner Library]

Thank you Tim. My library is using the xmlui interface and still uses the original workflow. I noticed the following line was uncommented.

<aspect name="Original Workflow" path="resource://aspects/Workflow/" />

I have the sword v1, rest api and oai modules enabled too.

--
All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/7eb58f71-d465-4c38-9e68-c9c007cfd0ban%40googlegroups.com.

[Tim Donohue]

Hi,

Since you are using the original workflow, the migration that is failing should have already been run​ on your 6.3 installation.  I wonder if somehow this migration was skipped accidentally whenever you upgraded from 5.x to 6.x, and now it's causing issues during the 7.x upgrade.  Basically, it sounds like your database is in an odd setup where you are using v6.3, but an older 5.7 migration was never run​.

One possible solution would be to first​ run this migration on your 6.x database (where it should succeed), and then​ upgrade to 7.x (at which point it won't be re-run again).

This would involve something like this:

1. On your 6.x install, run ./dspace database migrate ignored​ using the DSpace v6.3 codebase. Ensure all 5.x/6.x migrations run (you can look at them via ./dspace database info)
2. Then update to the  7.x codebase, and re-run the required "./dspace database migrate ignored".  This time it should ONLY run newer migrations that have been added since​ 6.x.

Tim

---

From: dspac...@googlegroups.com <dspac...@googlegroups.com> on behalf of Joyner Library <joyn...@gmail.com>
Sent: Monday, October 4, 2021 11:03 AM
To: Tim Donohue <tim.d...@lyrasis.org>
Cc: DSpace Technical Support <dspac...@googlegroups.com>
Subject: Re: [dspace-tech] Re: dspace 7 upgrade database errors

 

You received this message because you are subscribed to a topic in the Google Groups "DSpace Technical Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dspace-tech/AQscVep37pE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dspace-tech...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/CAOmWSh9Dv52YcZYTkXsVrYbmbTLo0%3Dh%3DJVHkFgP237LRZM6EyQ%40mail.gmail.com.

[Joyner Library]

Thank you Tim. We tried using the database migrate command on the current dspace server. Please see the log files attached. It did not give an error message in terminal and did not migrate the ignored sections.

Nick Crimi

Joyner Library

[Tim Donohue]

Hi Nick,

Just to clarify, did you run "./dspace migrate ignored" on your current server?  You need to use the "ignored" flag to trigger any migrations which are listed as "IGNORED".  And, in your "db info" output file, I see the failing migration is listed there as "IGNORED" (see the line that says: 

| 5.7.2017.05.05 | DS 3431 Add Policies for BasicWorkflow              |                     | Ignored |

Essentially, what we're trying to do here is ensure ALL these already "Ignored" migrations get run on your 6.x instance. That way, when you update to 7.x, they won't need to be run again.    The failure you were hitting in your 7.x upgrade seems to be related to these older 5.x "Ignored" migrations.

Tim

---

From: Joyner Library <joyn...@gmail.com>
Sent: Monday, October 4, 2021 1:11 PM