search

wasp-lang / wasp

The fastest way to develop full-stack web apps with React & Node.js.
https://wasp-lang.dev
MIT License
13.74k stars 1.18k forks source link

Add support for named managed dev database: `wasp db start <db-name>` #1972

Open vincanger opened 6 months ago

vincanger commented 6 months ago

When using wasp db start we only get the ability to create one dev database in relation to this wasp project.

However, sometimes you might want to have multiple development databases that you can start / stop as you want, and there is no easy way to do that via wasp db start, instead you have to manually handle multiple development databases and correctly set DATABASE_URL depending on which one you want to use.

Use case: running e2e tests locally

Instead of running them against our dev database and making a mess in it, it would be better to create a new db specifically for e2e tests. RIght now, to do this, you have to:

Use case: switching between git branches with different db schema

In this case, if you have just one dev database, you will need with each switch to migrate the db, which becomes complex if you have to migrate the data. You could keep cleaning up and re-seeding the database, so it is doable, but still it is not straight forward. Or of course you could handle the multiple databases manually, not through wasp start db, and then set up DATABASE_URL on your own, but that is also not super convenient.

Related discord convo: https://discord.com/channels/686873244791210014/1280669821477847151/1280669821477847151 .

Solution

Use a named managed dev db, e.g. wasp db start <db-name> wasp db start e2e-db would then be treated differently from wasp db start or wasp db start dev-db or wasp db start feature1 or wasp db start feature2 -> each of these would be a different database.

Martinsos commented 6 months ago

@infomiho said:

In Rails for example, they recognise that test is separate env from dev and production. By default they include a test env for the database which implies that there is a test database which is used in the tests.

https://guides.rubyonrails.org/testing.html#the-test-database

So, the idea of having a separate test DB which has its own "mock data" that gets loaded for tests is a great idea! For now, with our current setup, we only recognise dev and production envs - so not good for locally running e2e tests. It's okay for the CI setup though.

Martinsos commented 1 month ago

One more related discord convo: https://discord.com/channels/686873244791210014/1292902545462923264/1292902545462923264 .

Also use case with multiple branches.