goose icon indicating copy to clipboard operation
goose copied to clipboard

-no-versioning and -table options seem not to work

Open insanebaba opened this issue 2 years ago • 2 comments

I have 2 different directories

1. ./resources/db/migrations/       
├── 00001_create_a.sql
├── 00002_create_b.sql
├── 00003_create_c.sql
├── 00004_create_d.sql
├── 00005_create_e.sql
├── 00006_create_f.sql
└── 00007_create_g.sql
2. ./resources/db/seed/
├── 00001_seed_a.sql
├── 00002_seed_b.sql
├── 00003_seed_c.sql
└── 00004_seed_d.sql

I would like to seed the data from goose command line.

As you can see the versions of seed and migrations are different and are not in sync. I am not able to seed data from command line based on documentation.

I've used

-table,

but It doesn't do anything, It doesn't create a new table, as I was expecting

-no-versioning

Doesn't work at all, I don't know why is it even there. It doesn't redo last available migration in seed directory, nor does it give correct error. I tried redo with -no-versioning, doesn't work, I tried down-to and up-to , doesn't work.

My question at this point is, How can I initialize a new versioning table for seeds in db using goose cli? I don't want to manually run a create table command in db,

insanebaba avatar Sep 17 '22 10:09 insanebaba

The purpose of -no-versioning is to allow users to apply ad-hoc migrations, which are not tracked in the database, and thus have no version.

By adding -no-versioning flag (CLI) or supplying WithNoVersioning() option (library), we instruct goose to apply migrations but to ignore tracking the version in the database schema table.

Ad-hoc migrations with no versioning.

So the behaviour you observed is correct. Quite often "seeding" means you don't care to track those changes in the database.

If you do want to track the versions of 2 directories separately, you'll use 2 different commands to target different tables with -table. But I don't advise doing that because it's inevitable you'll mix up commands and apply the wrong directory against the wrong table. Furthermore, if there is a relationship between the directories you always have to coordinate applying them.

Sometimes you always want to seed a database with some data, in which case you'd just add those migrations as part of your normal versioned migrations.


I think this is what you're trying to do, using an example from this repository.

Run versioned migrations and track them in default table goose_db_version

$ goose -dir ./tests/e2e/testdata/postgres/migrations up               
2022/09/17 09:15:48 OK    00001_a.sql
2022/09/17 09:15:48 OK    00002_b.sql
2022/09/17 09:15:48 OK    00003_c.sql
2022/09/17 09:15:48 OK    00004_d.sql
2022/09/17 09:15:48 OK    00005_e.sql
2022/09/17 09:15:48 OK    00006_f.sql
2022/09/17 09:15:48 OK    00007_g.sql
2022/09/17 09:15:48 OK    00008_h.sql
2022/09/17 09:15:48 OK    00009_i.sql
2022/09/17 09:15:48 OK    00010_j.sql
2022/09/17 09:15:48 OK    00011_k.sql

Run other versioned migrations from a different directory and store against table foo

$ goose -table foo -dir ./tests/e2e/testdata/postgres/seed up
2022/09/17 09:16:00 OK    00001_a.sql
2022/09/17 09:16:00 OK    00002_b.sql

mfridman avatar Sep 17 '22 13:09 mfridman

I tried this one, but It doesn't take the passed table. How can I create this table from cli?

$ goose -table foo -dir ./tests/e2e/testdata/postgres/seed up
2022/09/17 09:16:00 OK    00001_a.sql
2022/09/17 09:16:00 OK    00002_b.sql

insanebaba avatar Sep 19 '22 15:09 insanebaba

Closing this issue, but tl;dr .. "no versioning" option explicitly disables tracking migration versions in the database. Which means you run your migrations like normal, and then seed the database with-no-versioning pointing at the seed directory.

If you want to keep track of the seed directory, then don't use -no-versioning and instead override the default table name with something like goose_db_seed.

mfridman avatar Nov 13 '23 14:11 mfridman