search

rbeckman-nextgen / test-mc

test-migration
1 stars 0 forks source link

New install or Migration #3635

Closed rbeckman-nextgen closed 4 years ago

rbeckman-nextgen commented 4 years ago

Mirth Connect Server 3.2.1.7650 Built on March 17, 2015 a) Existing old mirth database tables exist in a public schema in Postgresql. b) You create a new schema called 'mirth' in the same database. c) Install new mirth and point it to the new database and schema with: jdbc:postgresql://localhost:5432/mirthdb?schema=mirth as the URL. d) Startup mirth connect. It will try to migrate your old schema into the new one and create havoc. e) Mirth install or first startup should ask if we are migrating or creating new tables. f) Yes this is resolved by using another database inside of postgresql but even that message is not provided in anyway.

Imported Issue. Original Details: Reporter: stickybandit Created: 2015-05-04T12:23:21.000-0700

rbeckman-nextgen commented 4 years ago

First off, "?schema=mirth" is incorrect. Assuming you are the database administrator, you need to take care when creating or alerting your server, and take care to use the correct connection parameters. It sounds like this was a case of user-error where you pointed a new MC server instance to a different database than what you wanted.

For example if you look at [the actual PostgreSQL documentation|https://jdbc.postgresql.org/documentation/head/connect.html], you will see that there is no such "schema" parameter. Maybe it was there in a very old version of the driver or something, but I'm not sure where you got that. Always be sure to look at the documentation before yoloing the connection settings, if you don't want to accidentally mess something up.

For PostgreSQL, the correct thing to do is create a separate user, and alter that user's search_path to the specific schema you want. Also set the owner of that schema to said user. Then when you connect via JDBC with that user, it should be using the correct schema.

When connected using the correct user and search path, you shouldn't run into any problems where you accidentally overwrite anything in your other schema. However, Mirth Connect still won't quite run correctly yet, because it doesn't check against any specific schema pattern when checking the existence of tables or indicies. I've created a separate issue for that: MIRTH-3710

Imported Comment. Original Details: Author: narupley Created: 2015-05-05T10:33:15.000-0700

rbeckman-nextgen commented 4 years ago

Huh? We did have a separate user and 'schema=' is correct URL syntax. Not sure why you want to dodge this mirth issue.
But in any case we did the favor by letting Mirth know about it. Fix it or don't fix it. It is not our problem anymore since we found a workaround.

Imported Comment. Original Details: Author: stickybandit Created: 2015-05-05T10:46:29.000-0700

rbeckman-nextgen commented 4 years ago

I only moved it to a separate, more specific issue: MIRTH-3710

MC doesn't handle the separate schemata when checking for existence of tables, that's what the core issue entails. As for the "schema" property in the connection URL, where are you getting that from? The documentation specifies a "currentSchema" property to set the search path, but that's it. You may have been looking at an older version of the documentation or something?

Imported Comment. Original Details: Author: narupley Created: 2015-05-05T10:52:02.000-0700