I am rewriting a website that has a back-end database for containing meta-data that is displayed to the user when they enter a text code.


The old/existing system stored this data in XML files with a master index XML file that pointed the correct data file based on a GUID. The way this is currently handled for publishing to production is all changes are done in a "staging" environment with the files being stored on Cloudfront under a "staging" folder. When they want to push changes to production, they simply copy the file from "staging" to "production".

I have updated the system to use a RDB (Postgres locally and it will be Aurora on AWS for production). I am using Java for the API with JPA annotations and Spring Boot. I have a separate Java Admin UI App that manages the meta-data and a separate user-facing application that is the website in Angular. The product owner still wants to be able to test changes in lower environments before publishing them to production.


I was trying to find a solution for publishing and was thinking that I may just have a staging env and a production env. A coworker here said that maybe have the Staging Admin App normally point to the Staging API, but when publishing, have it point to the Production API instead and not have a production Admin App. The problem I am running into is primary keys. You cannot specify the primary key in JPA AND have it auto-generated if it doesn't exist. I tried several different ways to do that and it breaks if I try to insert 1, 3, 2.

Does anybody have any recommendations on how to handle this situation? Transfer data from one RDB to another RDB in a different env while keeping all relationships intact.

1 Answer 1


Could you solve this using a DevOps solutions, rather than code? If you separate content out from other data you are storing, you could use the power of the cloud to take a snapshot of your content database, then make it available to your production instance, using the AWS API SDK. You could then have it update the connection string in your production app for it's content DB. That would also make rolling forward and backward easy, as you could go back to the old content DB if something went awry for any reason.

  • I would not be able to solve this with DevOps since the user needs the ability to publish items as they are needed, but make multiple changes to be queued up. We can't just do a replace of the whole database. Jan 25, 2016 at 23:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.