"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." _ I agree, it makes no sense that the migration is attempting to create fixes for past versions. I don't think this is normally what software engineers / companies do, unless there is a zero-day bug or something like that. Normally I expect patches to older software items / packages to be in later releases, otherwise it becomes ridiculously confusing. I also think this may be a bug. One workaround may be just to remove the code in scripts that ask for this to occur. Or to create the column, and then delete the finished result at the end of the migration. Unsure.
On Thursday, October 14, 2021 at 10:47:36 AM UTC-5 S. T. wrote: > 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/db295efa-89f9-4403-ab7b-49d2a792d890n%40googlegroups.com.
