Portal

Can a Production instance of Semarchy have the schema containing Application tables renamed without breaking it (not the connected DSN just the physical back-end name)?

We are working on setting up our Production instance prior to launching our first Semarchy apps and integrations. I have a configuration question related to the Production instance. Here are my circumstances: 

My server team (overseas) set up the Production instance with a different name for the application table schema than we have in Dev. Dev was set up with a specific schema name "semarchy_data_location" , and Prod used a default name of "semarchy_data".

My Dev host server for Semarchy is PostgreSQL 12.3, Production is slightly different with version 12.4. 

The JDBC DSN is set up with the name from Dev even though the schema is not, so the imported model looks like it was able to deploy correctly and create tables okay in the Prod schema. 

I have outside integrations loading data using loading jobs and referring to the old schema name in Dev, so clearly they need to match. 

If I rename the schema in Prod to match Dev, will this break any dependencies for Semarchy...since the model deployed and presumably Semarchy is referring to the DSN resource by the alias that is the same as the actual schema name in Dev. 

Renaming the schema should be fine.

In general, there is no requirement for the PROD and DEV schemas to have the same name. And you're seeing that playing out in the lack of problems with using 2 different names.

Likewise, renaming the schema ought to be transparent to xDM because xDM will indeed refer to the schema only using the JNDI DSN, as you suggested. Normally I would drop and re-create the schema rather than rename it. Is that an option for you?

In general we will always advise that you should use exactly the same database version in both environments. It's simply a way to reduce risk. But I certainly can't think of anything that would cause problems between PostgreSQL 12.3 vs 12.4. I would really expect that difference to be a non-issue.

So you should be fine with either changing your integration jobs to match the current schema or with changing the schema name to match what your jobs expect. Therefore it's up to you to pick the option that seems simpler to you.