jhu-bids / TermHub

Web app and CLI tools for working with biomedical terminologies. https://github.com/orgs/jhu-bids/projects/9/views/7
https://bit.ly/termhub
GNU General Public License v3.0
8 stars 10 forks source link

DB: 2 schemas/db's for dev & prod #214

Open joeflack4 opened 1 year ago

joeflack4 commented 1 year ago

Overview

@Sigfried I think we spoke briefly about this. We want to split prod and dev into two different databases (or schema). As I'm doing the DB refresh, I think it'll come up in the future that we need to do stuff that affects the DB, and we don't want that to affect users. The DB is expensive, so you had the idea of using a different schema for the development deployment. I think that sounds like a good idea.

Current blockers

Main thing holding us back is that these would need to be kept in sync. And that could be difficult.

Sub-tasks

hugwuoke commented 1 year ago

I believe this has been figured out but tbh I don't completely understand what is costly etc.

joeflack4 commented 1 year ago

This one hasn't been done. I changed the title from 'development' to 'development deployment'. For local development we can use a local database. But the issue here is that http://bit.ly/termub and http://bit.ly/termub-dev share the same exact database. This is actually a really bad, not normal software development practice. We want a stable production app where when we are developing stuff and something goes wrong, it won't be affected.

Regarding the cost, I think our Postgres database on Azure is like $80/mon. The typical situation is that we'd spin up another DB. But if we want to save $80/mo, we can just use another Postgres schema. So right now, the schema we use for both prod/develop is n3c. But we could change it for example such that prod uses n3c and develop uses n3c_develop.

@Sigfried @hugwuoke I've marked this with medium urgency but really it kinda should be high. This is something I could probably do after most of the DB refresh issues are completed.