Which DSpace version is your dump from and which DSpace version were you trying to import it into? If you don't know, you can check the schema_migration table in your sql dump (assuming the dump is from DSpace 4.0 or newer).
The migration of DSpace entity identifiers from integers to UUIDs occurred from 5.x -> 6.0, specifically this migration: https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace- api/src/main/resources/org/dspace/storage/rdbms/sqlmigration/postgres/V6.0_ 2015.03.07__DS-2701_Hibernate_migration.sql While it is possible to take the sql dump from an older DSpace version and run a newer DSpace version on it which will migrate it, but in your case I recommend that you don't attempt it before making sure that the restored dump works on the same DSpace version. Useful commands (read the docs): [dspace]/bin/dspace database info (show status of migrations) [dspace]/bin/dspace database migrate [dspace]/bin/dspace database clean (this drops all dspace tables; it asks for confirmation, but triple-check the output to make sure which you're working with the right database) Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette On Thu, Mar 9, 2017 at 8:17 PM, Walter Rutherford <wlrutherf...@gmail.com> wrote: > > I'm building a replacement DSpace website. I had DSpace6 installed using > Tomcat 9.0.0 > and it seemed to be fine. But when I loaded postgres with a dump from the > original site I > got some errors about variables being integers instead of uuids. I scanned > the entire dump > file but didn't find a single reference to uuid or UUID. > > I'd interrupted the dump because of the thousands of errors it was > spewing. I saw that > the dump begins by dropping the databases so I tried again but let it run > despite the > errors. It built the tables, with double the number of expected rows. > Oops! I guess dropping > the databases wasn't enough. So I gpt ot to drop the databases AND tables > first. There > were again some errors the second time but the tables were the right size. > The dspace > database test and email test worked just fine. I found a dspace password > error in the daily > log but fixed that before I went home for the day. > > But today when I navigated to the xmlui home page I got this: > ERROR: column metadata1_.dspace_object_id does not exist Position: 345 > Normally I just see a vanilla DSpace home page. I haven't seen this error > before but that > might be good news if it means DSpace is attempting to connect to the > postgres database. > > Note: I first tried this out on a guinea pig system and it read the > postgres dump file without > any complaints (that I noticed). But that system doesn't have DSpace so it > might have the > same problem but it just isn't visible without DSpace. Or the issue could > be just on the new > system between DSpace/(omcat/java and postgres. > > Now I just want to start from a clean slate before continuing. Did I miss > something trying to > clean up the first attempt? What's the quickest, cleanest way to removed > the entire dump > and start over? > > -- > 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+unsubscr...@googlegroups.com. > To post to this group, send email to dspace-tech@googlegroups.com. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
