You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PR #198 introduces a remote 'development' database that is available to local development. We should have a team discussion to ensure we have consistent and maintainable expectations around the use of this environment.
Acceptance criteria
Reach a consensus on DB usage
Document in the readme
The text was updated successfully, but these errors were encountered:
My philosophy is to have a one to one relationship between application and database instances. In other words, a development database should exclusively serve one development application. Accordingly, local applications would be served by only local database instances.
However, I recognize that some folks will want to avoid setting up the database locally just to make changes to the API. As a compromise, I suggest we still provide the development database. However, it is only used for tickets that do not require database schema changes. Any work that requires modifications to the database schema must be done against a local database instance.
If making it impossible for a local API to use a remote DB is a requirement
Documenting an offline discussion around this:
Making it technically impossible for a local api to use a remote db is a non-goal. This is more about establishing cultural workflow expectations
Background
PR #198 introduces a remote 'development' database that is available to local development. We should have a team discussion to ensure we have consistent and maintainable expectations around the use of this environment.
Acceptance criteria
The text was updated successfully, but these errors were encountered: