Hi David,
No, no need to be concerned. "Baseline" and "OutOfOrder" are terms from
Flywaydb.org (the database upgrade tool we use. "Baseline" just lets you
know which was the *first* Flyway migration ever run on your database (i.e.
the baseline version you started from). "OutOfOrder" just means
Thanks, Tim. I've added
db.schema = public
to my local.cfg and that appears to have helped with the issue. Do I need
to be concerned that my ./dspace database info shows these 2 lines as
"Baselin" and "OutOrdr" instead of "Success" like all of the others?
1 | << Flyway Init >>
Hi David,
No, what I was referring to is an automatic update of the local (bitstream
format and metadata) registries that happens *AFTER* all the database
upgrade scripts run (this update is triggered by a callback script which
requires the database be updated first -- as the registry update is
Below is the result of ./dspace database info. Is the ignored DS-2818
registry update what you were referring to as updating the local DSpace
registries?
Using DSpace installation in: C:\dspace
Database Type: postgres
Database URL: jdbc:postgresql://localhost:5432/dspace
Database Schema:
Hi David,
That's definitely unexpected. It sounds like your database upgrade
succeeded, but failed to update your local DSpace registries (the Bitstream
Format Registry). This syntax error is very odd, and unfortunately is
nothing I've seen before:
2019-03-01 13:09:16,849 WARN
Thanks, Tim. I deleted the duplicate COLLECTION_29_DEFAULT_READ group and
the migration proceeded past. It now shows all of the migrations as
successful except DS-2818 registry update, which I'm assuming is normal.
I'm apparently having an issue somewhere else now, though. When I browse to
my
Hi David,
You are correct, this is related to the bug report in DS-2824. The problem
is that you seem to have somehow created two Groups of the *same name*. In
your situation, the errors is saying you have two groups named
"COLLECTION_29_DEFAULT_READ". Group Names are supposed to be unique (and
