Hey folks, or anyone interested - here is the log of the DB repair function on our 6.0 DB. We did get a single table repair, but it was not the table in question. We are attempting to run the migration script again, to see what happens. Thanks again to everyone who has attempted to help. It is much appreciated.
2021-10-14 12:41:13,206 INFO org.dspace.importer.external.service.ImportService @ Loading 1 import sources. 2021-10-14 12:41:14,032 INFO org.dspace.core.LoggerServiceImpl @ Using dspace provided log configuration (log.init.config) 2021-10-14 12:41:14,032 INFO org.dspace.core.LoggerServiceImpl @ Loading: /srv/dspace63/config/log4j.properties 2021-10-14 12:41:14,183 INFO org.dspace.storage.rdbms.DatabaseUtils @ Loading Flyway DB migrations from: filesystem:/srv/dspace63/etc/postgres, classpath:org.dspace.storage.rdbms.sqlmigration.postgres, classpath:org.dspace.storage.rdbms.migration 2021-10-14 12:41:14,186 INFO org.flywaydb.core.internal.util.VersionPrinter @ Flyway 4.0.3 by Boxfuse 2021-10-14 12:41:14,196 INFO org.flywaydb.core.internal.dbsupport.DbSupportFactory @ Database: jdbc:postgresql://localhost:5432/dspace (PostgreSQL 9.4) 2021-10-14 12:41:14,241 INFO org.flywaydb.core.internal.metadatatable.MetaDataTableImpl @ Repair of failed migration in metadata table "public"."schema_version" not necessary. No failed migration detected. 2021-10-14 12:41:14,268 INFO org.flywaydb.core.internal.command.DbRepair @ Successfully repaired metadata table "public"."schema_version" (execution time 00:00.030s). On Thursday, October 14, 2021 at 12:17:22 PM UTC-5 S. T. wrote: > Hi folks; here is our info dump 6.3 with 6.0 DB > > you can see the ignored line for the metadata value index down there at > the bottom, that is where the install fails, of course. Because the column > it is looking for doesnt' exist. > > However, nobody has answered the question as to why is this even part of > the migration process? Where is this index in 7.0? Or in 6.xx? It is not in > that table. Is it moved by other migration scripts to another table? That > index does exist in several other tables, but not this one, according to > both schemas. > > Database URL: jdbc:postgresql://localhost:5432/dspace > Migrating database to latest version AND running previously "Ignored" > migrations... (Check 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.main(DatabaseUtils.java:187) > 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 > V5.7_2017.04.11__DS-3563_Index_metadatavalue_resource_type_id_column.sql > failed > > ----------------------------------------------------------------------------------------- > SQL State : 42703 > Error Code : 0 > Message : ERROR: column "resource_type_id" does not exist > Location : > org/dspace/storage/rdbms/sqlmigration/postgres/V5.7_2017.04.11__DS-3563_Index_metadatavalue_resource_type_id_column.sql > > (/srv/dspace63/bin/file:/srv/dspace63/lib/dspace-api-6.3.jar!/org/dspace/storage/rdbms/sqlmigration/postgres/V5.7_2017.04.11__DS-3563_Index_metadatavalue_resource_type_id_column.sql) > Line : 16 > Statement : CREATE INDEX metadatavalue_resource_type_id_idx ON > metadatavalue (resource_type_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) > ... 7 more > Caused by: org.postgresql.util.PSQLException: ERROR: column > "resource_type_id" does not exist > 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) > ... 23 more > > On Thursday, October 14, 2021 at 11:20:06 AM UTC-5 S. T. wrote: > >> Hi Tim - yes, agreed. We were running 6.0. The ignore command was in >> operation for our migration, and it claims it is not needed, and so it is >> ignored. Except it is not ignored, and the DB fails on request. >> Additionally, I am not sure what you are saying because this field doesn't >> exist in the 7/xx DB schema for that table. SO what gives? Is it created, >> and then migrated through additional SQL migration scripts to another >> table, this index it is trying to create? Because it doesn't not exist in >> 7, so why is the script desperately trying to make it so? >> >> On Thursday, October 14, 2021 at 11:04:30 AM UTC-5 Tim Donohue wrote: >> >>> Hi Steven, >>> >>> What does your "dspace database info" command return? >>> We'd need more information here to help debug it. This seems like a >>> very odd error to me as well, as that migration was initially added in 5.7 >>> and ported to 6.1... so, if you were already running 6.1 or above, this >>> migration * should have already run for you*. >>> >>> That said, it's possible your "dspace database info" command would >>> provide us with additional hints. I'm assuming that somehow this >>> migration may not have ever been applied to your 6.x site....and now that >>> you are updating to 7.x, it's causing issues. >>> >>> Tim >>> ------------------------------ >>> *From:* [email protected] <[email protected]> on behalf >>> of S. T. <[email protected]> >>> *Sent:* Thursday, October 14, 2021 10:47 AM >>> *To:* DSpace Technical Support <[email protected]> >>> *Subject:* [dspace-tech] Re: Seemingly crazy catch 22 Dspace DB >>> migration loop question!!! >>> >>> Thanks Joel, I appreciate the help. I guess I should search the Jira for >>> Dspace on their github repo, and / or submit this bug. I am assuming they >>> have a Jira and a github repo.Let me run those commands, and I will share. >>> >>> On Thursday, October 14, 2021 at 7:56:24 AM UTC-5 [email protected] >>> wrote: >>> >>> Steven, >>> >>> I claim to be no expert, but maybe you (and another post >>> <https://groups.google.com/g/dspace-tech/c/1paSeuUkjFo> from September) >>> stumbled upon a bug? Can you share the results of the following commands? >>> >>> >>> *[dspace]/bin/dspace database validate * >>> *[dspace]/bin/dspace database info* >>> >>> It's suspicious that you started on version 6 and the Flyaway migration >>> is attempting to issue a patch for something that existed in version 5.7. >>> >>> Just for fun, you might want to try this, too, if you haven't already. >>> >>> >>> *[dspace]/bin/dspace database repair * >>> >>> --Joel >>> >>> >>> >>> >>> On Wednesday, October 13, 2021 at 5:47:46 PM UTC-4 [email protected] >>> wrote: >>> >>> We are trying to upgrade our system from 6 to 7, we are following all >>> the steps. >>> >>> We get this message on DB migration: >>> Migration >>> V5.7_2017.04.11__DS-3563_Index_metadatavalue_resource_type_id_column.sql >>> failed >>> >>> When we attempt to update the DB, if fails right there, because it is >>> (?) trying to create a field WHICH APPARENTLY DOES NOT EXIST in 6.x or 7.x >>> from a previous field THAT NEVER EXISTED ON OUR 6.x install. >>> >>> This script, which is part of the Flyway DB upgrade auto process >>> >>> >>> org/dspace/storage/rdbms/sqlmigration/postgres/V5.7_2017.04.11__DS-3563_Index_metadatavalue_resource_type_id_column.sql >>> >>> Contents are: >>> DROP INDEX IF EXISTS metadatavalue_resource_type_id_idx; CREATE INDEX >>> metadatavalue_resource_type_id_idx ON metadatavalue (resource_type_id); >>> >>> However, WE started with V 6.0. So, (1) that column did not exist in the >>> 6.0 schema. (2) Furthermore, the field it is trying to create USING the >>> value from that 5.7 field, also DOES NOT EXIST in the schema for 6.xx OR >>> 7.xx. >>> >>> So, the migration script seems to be trying to alter the metadatavalue >>> table using a column which doesn't exist to create a column that doesn't >>> apparently exist in anyone's backend. >>> >>> Can anyone who either knows migrations very well, or the Dspace backend >>> care to comment or assist? This is so super frustrating and confusing. What >>> are we missing? >>> >>> Thanks so much >>> >>> Steven Turner >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/dspace-tech/6fe30d91-4b79-48c6-aa30-2e13ce040132n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/dspace-tech/6fe30d91-4b79-48c6-aa30-2e13ce040132n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/e8ab00d6-4203-4ecb-b0d5-846df5d2cff7n%40googlegroups.com.
