Error dirty database version 1 fix and force version

Name already in use

migrate / FAQ.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

5 contributors

Users who have contributed to this file

Copy raw contents

Copy raw contents

How is the code base structured?

Why is there no source/driver.go:Last() ?

It’s not needed. And unless the source has a «native» way to read a directory in reversed order, it might be expensive to do a full directory scan in order to get the last element.

What is a NilMigration? NilVersion?

NilMigration defines a migration without a body. NilVersion is defined as const -1.

What is the difference between uint(version) and int(targetVersion)?

version refers to an existing migration version coming from a source and therefore can never be negative. targetVersion can either be a version OR represent a NilVersion, which equals -1.

What’s the difference between Next/Previous and Up/Down?

Why two separate files (up and down) for a migration?

It makes all of our lives easier. No new markup/syntax to learn for users and existing database utility tools continue to work as expected.

How many migrations can migrate handle?

Whatever the maximum positive signed integer value is for your platform. For 32bit it would be 2,147,483,647 migrations. Migrate only keeps references to the currently run and pre-fetched migrations in memory. Please note that some source drivers need to do build a full «directory» tree first, which puts some heat on the memory consumption.

Are the table tests in migrate_test.go bloated?

Yes and no. There are duplicate test cases for sure but they don’t hurt here. In fact the tests are very visual now and might help new users understand expected behaviors quickly. Migrate from version x to y and y is the last migration? Just check out the test for that particular case and know what’s going on instantly.

What is Docker being used for?

Why not just use docker-compose?

It doesn’t give us enough runtime control for testing. We want to be able to bring up containers fast and whenever we want, not just once at the beginning of all tests.

Can I maintain my driver in my own repository?

Yes, technically thats possible. We want to encourage you to contribute your driver to this respository though. The driver’s functionality is dictated by migrate’s interfaces. That means there should really just be one driver for a database/ source. We want to prevent a future where several drivers doing the exact same thing, just implemented a bit differently, co-exist somewhere on GitHub. If users have to do research first to find the «best» available driver for a database in order to get started, we would have failed as an open source community.

Can I mix multiple sources during a batch of migrations?

What does «dirty» database mean?

Before a migration runs, each database sets a dirty flag. Execution stops if a migration fails and the dirty state persists, which prevents attempts to run more migrations on top of a failed migration. You need to manually fix the error and then «force» the expected version.

What happens if two programs try and update the database at the same time?

Database-specific locking features are used by some database drivers to prevent multiple instances of migrate from running migrations at the same time the same database at the same time. For example, the MySQL driver uses the GET_LOCK function, while the Postgres driver uses the pg_advisory_lock function.

Do I need to create a table for tracking migration version used?

No, it is done automatically.

Can I use migrate with a non-Go project?

Yes, you can use the migrate CLI in a non-Go project, but there are probably other libraries/frameworks available that offer better test and deploy integrations in that language/framework.

I have got an error Dirty database version 1. Fix and force version . What should I do?

Источник

Name already in use

migrate / GETTING_STARTED.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

3 contributors

Users who have contributed to this file

Copy raw contents

Copy raw contents

Before you start, you should understand the concept of forward/up and reverse/down database migrations.

Configure a database for your application. Make sure that your database driver is supported here.

Create some migrations using migrate CLI. Here is an example:

Once you create your files, you should fill them.

IMPORTANT: In a project developed by more than one person there is a chance of migrations inconsistency — e.g. two developers can create conflicting migrations, and the developer that created their migration later gets it merged to the repository first. Developers and Teams should keep an eye on such cases (especially during code review). Here is the issue summary if you would like to read more.

Consider making your migrations idempotent — we can run the same sql code twice in a row with the same result. This makes our migrations more robust. On the other hand, it causes slightly less control over database schema — e.g. let’s say you forgot to drop the table in down migration. You run down migration — the table is still there. When you run up migration again — CREATE TABLE would return an error, helping you find an issue in down migration, while CREATE TABLE IF NOT EXISTS would not. Use those conditions wisely.

In case you would like to run several commands/queries in one migration, you should wrap them in a transaction (if your database supports it). This way if one of commands fails, our database will remain unchanged.

Run your migrations through the CLI or your app and check if they applied expected changes. Just to give you an idea:

Just add the code to your app and you’re ready to go!

Before commiting your migrations you should run your migrations up, down, and then up again to see if migrations are working properly both ways. (e.g. if you created a table in a migration but reverse migration did not delete it, you will encounter an error when running the forward migration again) It’s also worth checking your migrations in a separate, containerized environment. You can find some tools at the end of this document.

IMPORTANT: If you would like to run multiple instances of your app on different machines be sure to use a database that supports locking when running migrations. Otherwise you may encounter issues.

Forcing your database version

In case you run a migration that contained an error, migrate will not let you run other migrations on the same database. You will see an error like Dirty database version 1. Fix and force version , even when you fix the erred migration. This means your database was marked as ‘dirty’. You need to investigate the migration error — was your migration applied partially, or was it not applied at all? Once you know, you should force your database to a version reflecting it’s real state. You can do so with force command:

Once you force the version and your migration was fixed, your database is ‘clean’ again and you can proceed with your migrations.

For details and example of usage see this comment.

Источник

Discussion on: How to write & run database migration in Golang

Getting this error while migratedown

«Dirty database version -1. Fix and force version.»

can anyone help with a solution! it will be a great help if you can.

Hi Apoorv, try this cmd first

migrate -path db/migration -database «postgresql://root:secret@localhost:5432/simple_bank?sslmode=disable» force 1

and then run makefile cmd

it should solve this issue. Here’s the docs for it
github.com/golang-migrate/migrate/.

For further actions, you may consider blocking this person and/or reporting abuse

DEV Community 👩‍💻👨‍💻 — A constructive and inclusive social network for software developers. With you every step of your journey.

Built on Forem — the open source software that powers DEV and other inclusive communities.

Made with love and Ruby on Rails. DEV Community 👩‍💻👨‍💻 © 2016 — 2023.

We’re a place where coders share, stay up-to-date and grow their careers.

Источник

«Dirty database version» error. #217

first of all, thanks for great project. I now trying to work with v3, and having some issues related to, well, understanding error messages. For example, during normal development workflow, creating new SQL-files, there was an error in one of them and migration failed. After fixing the error, on the next run, I got message:

Dirty database version 4. Fix and force version.

And the problem is it’s not clear what does mean «dirty database» in this context and how to «fix it» and what does mean «force version». I haven’t found explanation in the docs or issues. Of course, as it’s development env, I can just drop the db and recreate from scratch, but I suppose there should be «official» way to fix dirty database 🙂

PS. I’m running migrations from code, not from CLI, if it matters.

Thanks in advance!

UPD: After some digging, I ended up updating schema_migrations table manually, by UPDATE .. SET dirty=false and playing with version, but it’s not how it supposed to work, is it?

The text was updated successfully, but these errors were encountered:

or when using the cli:
migrate force V — Set version V but don’t run migration (ignores dirty state)

Does that answer your question? Can you help to make the docs more clear?

Thanks @mattes! It’s weird (or maybe not) how I didn’t find this part in FAQ, deliberately searching for the explanation of dirty state.

Generally I think what really should help is more verbose errors descriptions. Descriptions written with zero knowledge user reading them in mind. Like instead of «no change» it could be something like «Your database already is up to date and this command makes no change. Probably you wanted to run bla-bla-bla» . 🙂

In case of «Dirty database version. Fix and force version.» I guess it’s enough to tell how exactly to «force the version». Something like «After unsuccessful migration, database is marked as dirty at migration version V. Fix the issue and use ‘migrate force V’ to forcefully update version».

I’m not doing PR on this, because I’m sure I’m not aware of all use cases where these errors might occur and you can come up with much better error message text. But idea is that more verbose self-explanatory errors would be a huge step forward in usability of migrate .

Источник

Dirty database version 1. Fix and force version #282

the error appears as below when migrate timeout:

Steps to Reproduce
Steps to reproduce the behavior:

1. do migrate timeout
2. migrate again

Expected Behavior
migrate again could automatically solve this problem and do migrate normally.

The text was updated successfully, but these errors were encountered:

Timeouts may occur and the correct fix is not obvious, so user intervention is necessary.
e.g. The migration could have never applied, partially applied, or fully applied

@dhui How to fix Dirty database status ? Is there any documents for this?

@duyanghao Force to a previous version and then run «up» again.

So if you get an error in version 10, fix the error and then force it to version 9. Afterwards you can migrate again.

@duyanghao Force to a previous version and then run «up» again.

So if you get an error in version 10, fix the error and then force it to version 9. Afterwards you can migrate again.

@anihex Could you please give an example of fixing Dirty database status as described above?

@duyanghao Of course I can.

Let’s assume I want to create a new table. But I made a «slight» mistake (missing Primary Key).

Now I try to migrate it:

migrate will refuse this:

Now I fixed it and added the PRIMARY KEY to the migration:

If I try to migrate again, migrate will STILL refuse:

So I have to go the last successfull version, which is 15.

If i migrate again, the output will now be:

The same works if you want to go down. But if would be 17 in this case, not 15.
I hope this helps a bit.

Let’s assume I want to create a new table. But I made a «slight» mistake (missing Primary Key).

Now I try to migrate it:

migrate will refuse this:

Now I fixed it and added the PRIMARY KEY to the migration:

If I try to migrate again, migrate will STILL refuse:

So I have to go the last successfull version, which is 15.

If i migrate again, the output will now be:

The same works if you want to go down. But if would be 17 in this case, not 15.
I hope this helps a bit.

@anihex Thank for your reply, that really helps a lot.

Maybe I am missing something here. If we are running migrations within a transaction, why do we need to mark the database as dirty? Asking this because it slows down rapid iterations on the migration if the developer has to force after every failure, and when it is the very first migration you can’t force it to the version 000000

@bkakadiya42 I had the same issue, ended up resetting my entire DB to start clean and then fix my migration file. Hope that helps!

It helps bandaid the problem, but it still leaves the question open why a failed transaction makes the database dirty. This must be a bug. The «force» UX is also very user hostile.

Maybe I am missing something here. If we are running migrations within a transaction, why do we need to mark the database as dirty? Asking this because it slows down rapid iterations on the migration if the developer has to force after every failure, and when it is the very first migration you can’t force it to the version 000000

Spot on. Error on first migration seems irrecoverable through migrate‘s interface. I will hack away and drop the schema_migrations table (if dirty && Version==1) but this is clearly an abstraction violation.
Also, all of this is just silly when using Postgres (or any other db with transaction support in schema changes for that matter)

Didn’t understood why the issue is marked as resolved, even the initial question refers to error on version 1 but all answers just seem to ignore that detail. Maybe I’m missing something as well. The docs don’t seem to scratch this itch tough.

Some possible ways this lib could help the developer in tackling this corner case I can think of:

• Allowing disabling the dirty feature
• Adding method to drop schema_migrations table
• Never setting first version as dirty (probably incoherent, bad idea)

All for helping out, just didn’t fully understood if this is something recognized as a problem.
I really (really) don’t want to sound like a jerk, but this bug makes the lib unusable in production. I cannot have an application that out of the blue requires a human messing with the DB.

Источник

@duyanghao Of course I can.

Let’s assume I want to create a new table. But I made a «slight» mistake (missing Primary Key).

BEGIN;

CREATE TABLE auth_users (
	id BIGSERIAL,

	name VARCHAR(255),
	superior_id BIGINT REFERENCES auth_users
);

COMMIT;

Now I try to migrate it:

migrate -path migrations/ -database postgres://test:test@localhost/dummy?sslmode=disable up

migrate will refuse this:

error: 2 errors occurred:
	* migration failed: there is no primary key for referenced table "auth_users" in line 0: BEGIN;

CREATE TABLE auth_users (
	id BIGSERIAL,

	name VARCHAR(255),
	superior_id BIGINT REFERENCES auth_users
);

COMMIT;
 (details: pq: there is no primary key for referenced table "auth_users")
	* pq: current transaction is aborted, commands ignored until end of transaction block in line 0: SELECT pg_advisory_unlock($1)

Now I fixed it and added the PRIMARY KEY to the migration:

BEGIN;

CREATE TABLE auth_users (
	id BIGSERIAL PRIMARY KEY,

	name VARCHAR(255),
	superior_id BIGINT REFERENCES auth_users
);

COMMIT;

If I try to migrate again, migrate will STILL refuse:

error: Dirty database version 16. Fix and force version.

So I have to go the last successfull version, which is 15.

migrate -path migrations/ -database postgres://test:test@localhost/dummy?sslmode=disable force 15

If i migrate again, the output will now be:

16/u create_auth_users (17.608619ms)

The same works if you want to go down. But if would be 17 in this case, not 15.
I hope this helps a bit.

Name already in use

migrate / cmd / migrate / README.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

5 contributors

Users who have contributed to this file

Copy raw contents

Copy raw contents

Download pre-built binary (Windows, MacOS, or Linux)

Linux (*.deb package)

With Go toolchain

1. Requires a version of Go that supports modules. e.g. Go 1.11+
2. These examples build the cli which will only work with postgres. In order to build the cli for use with other databases, replace the postgres build tag with the appropriate database tag(s) for the databases desired. The tags correspond to the names of the sub-packages underneath the database package.
3. Similarly to the database build tags, if you need to support other sources, use the appropriate build tag(s).
4. Support for build constraints will be removed in the future: #60
5. For versions of Go 1.15 and lower, make sure you’re not installing the migrate CLI from a module. e.g. there should not be any go.mod files in your current directory or any directory from your current directory to the root

So let’s say you want to run the first two migrations

If your migrations are hosted on github

The CLI will gracefully stop at a safe point when SIGINT (ctrl+c) is received. Send SIGKILL for immediate halt.

Reading CLI arguments from somewhere else

Источник

Name already in use

migrate / README.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

Copy raw contents

Copy raw contents

Database migrations written in Go. Use as CLI or import as library.

• Migrate reads migrations from sources and applies them in correct order to a database.
• Drivers are «dumb», migrate glues everything together and makes sure the logic is bulletproof. (Keeps the drivers lightweight, too.)
• Database drivers don’t assume things or try to correct user input. When in doubt, fail.

Database drivers run migrations. Add a new database?

Database connection strings are specified via URLs. The URL format is driver dependent but generally has the form: dbdriver://username:password@host:port/dbname?param1=true&param2=false

Any reserved URL characters need to be escaped. Note, the % character also needs to be escaped

Explicitly, the following characters need to be escaped: ! , # , $ , % , & , ‘ , ( , ) , * , + , , , / , : , ; , = , ? , @ , [ , ]

It’s easiest to always run the URL parts of your DB connection URL (e.g. username, password, etc) through an URL encoder. See the example Python snippets below:

Source drivers read migrations from local or remote sources. Add a new source?

• Filesystem — read from filesystem
• io/fs — read from a Go io/fs
• Go-Bindata — read from embedded binary data (jteeuwen/go-bindata)
• pkger — read from embedded binary data (markbates/pkger)
• GitHub — read from remote GitHub repositories
• GitHub Enterprise — read from remote GitHub Enterprise repositories
• Bitbucket — read from remote Bitbucket repositories
• Gitlab — read from remote Gitlab repositories
• AWS S3 — read from Amazon Web Services S3
• Google Cloud Storage — read from Google Cloud Platform Storage

Источник

golang-migrate/migrate

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

Database migrations written in Go. Use as CLI or import as library.

• Migrate reads migrations from sources and applies them in correct order to a database.
• Drivers are «dumb», migrate glues everything together and makes sure the logic is bulletproof. (Keeps the drivers lightweight, too.)
• Database drivers don’t assume things or try to correct user input. When in doubt, fail.

Database drivers run migrations. Add a new database?

Database connection strings are specified via URLs. The URL format is driver dependent but generally has the form: dbdriver://username:password@host:port/dbname?param1=true&param2=false

Any reserved URL characters need to be escaped. Note, the % character also needs to be escaped

Explicitly, the following characters need to be escaped: ! , # , $ , % , & , ‘ , ( , ) , * , + , , , / , : , ; , = , ? , @ , [ , ]

It’s easiest to always run the URL parts of your DB connection URL (e.g. username, password, etc) through an URL encoder. See the example Python snippets below:

Source drivers read migrations from local or remote sources. Add a new source?

• Filesystem — read from filesystem
• io/fs — read from a Go io/fs
• Go-Bindata — read from embedded binary data (jteeuwen/go-bindata)
• pkger — read from embedded binary data (markbates/pkger)
• GitHub — read from remote GitHub repositories
• GitHub Enterprise — read from remote GitHub Enterprise repositories
• Bitbucket — read from remote Bitbucket repositories
• Gitlab — read from remote Gitlab repositories
• AWS S3 — read from Amazon Web Services S3
• Google Cloud Storage — read from Google Cloud Platform Storage

Источник

Name already in use

migrate / GETTING_STARTED.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

Copy raw contents

Copy raw contents

Before you start, you should understand the concept of forward/up and reverse/down database migrations.

Configure a database for your application. Make sure that your database driver is supported here.

Create some migrations using migrate CLI. Here is an example:

Once you create your files, you should fill them.

IMPORTANT: In a project developed by more than one person there is a chance of migrations inconsistency — e.g. two developers can create conflicting migrations, and the developer that created their migration later gets it merged to the repository first. Developers and Teams should keep an eye on such cases (especially during code review). Here is the issue summary if you would like to read more.

Consider making your migrations idempotent — we can run the same sql code twice in a row with the same result. This makes our migrations more robust. On the other hand, it causes slightly less control over database schema — e.g. let’s say you forgot to drop the table in down migration. You run down migration — the table is still there. When you run up migration again — CREATE TABLE would return an error, helping you find an issue in down migration, while CREATE TABLE IF NOT EXISTS would not. Use those conditions wisely.

In case you would like to run several commands/queries in one migration, you should wrap them in a transaction (if your database supports it). This way if one of commands fails, our database will remain unchanged.

Run your migrations through the CLI or your app and check if they applied expected changes. Just to give you an idea:

Just add the code to your app and you’re ready to go!

Before commiting your migrations you should run your migrations up, down, and then up again to see if migrations are working properly both ways. (e.g. if you created a table in a migration but reverse migration did not delete it, you will encounter an error when running the forward migration again) It’s also worth checking your migrations in a separate, containerized environment. You can find some tools at the end of this document.

IMPORTANT: If you would like to run multiple instances of your app on different machines be sure to use a database that supports locking when running migrations. Otherwise you may encounter issues.

Forcing your database version

In case you run a migration that contained an error, migrate will not let you run other migrations on the same database. You will see an error like Dirty database version 1. Fix and force version , even when you fix the erred migration. This means your database was marked as ‘dirty’. You need to investigate the migration error — was your migration applied partially, or was it not applied at all? Once you know, you should force your database to a version reflecting it’s real state. You can do so with force command:

Once you force the version and your migration was fixed, your database is ‘clean’ again and you can proceed with your migrations.

For details and example of usage see this comment.

Источник

How to write & run database migration in Golang

When working with database, schema migration is one important task that we often have to do throughout the application lifetime to adapt to new business requirements.

In this lecture, we will learn how to write and run database schema migration in Golang using golang-migrate library.

Install golang-migrate

Golang-migrate works with many different database engines like postgres, mysql, mongo, cockroach, etc.

Let’s open this CLI documentation to see how to install it. I’m on a mac, so I will use Homebrew.

Exit fullscreen mode

Migrate gives us several commands:

• The first one is create , which we can use to create new migration files.
• The 2nd one is goto , which will migrate the schema to a specific version.
• Then the up or down commands to apply all or N up or down migrations.

There are several more commands, but in most of the time, we will work with create , up , and down .

Alright, migrate is successfully installed. We can run migrate -help to read its manual.

Create a new migration

OK, now I’m gonna create a new folder for our Simple Bank project. And inside, I will create a new folder db/migration to store all of our migration files.

Exit fullscreen mode

Then let’s create the 1st migration file to initialise our Simple Bank’s database schema.

Start with migrate create . Then the extension of the file will be sql , and the directory to store it is db/migration .

Exit fullscreen mode

We use the -seq flag to generate a sequential version number for the migration file. And finally the name of the migration, which is init_schema in this case.

As you can see, 2 migration files have been generated for us. They both have version 1 in the file name’s prefix, but their suffixes are different: 1 file is up and the other is down . Why?

Up/down migration

Well, basically it’s a best practice when writing database migration. The up script is run to make a forward change to the schema. And the down script is run if we want to revert the change made by the up script.

So when we run migrate up command, The up script files inside db/migration folder will be run sequentially by the order of their prefix version.

On the contrary, when we run migrate down command, the down-script files inside db/migration folder will be run sequentially by the reverse order of their prefix version.

Aright, now let’s open the simple_bank.sql file that we’ve generated in previous lectures. I’m gonna copy all content of this file and paste it to the init_schema.up.sql file.

Exit fullscreen mode

For the init_schema.down.sql file, we should revert the changes made by the up script. In this case, the up script creates 3 tables: accounts , transfers , and entries . So the down script should remove all of them. We use the DROP TABLE query for this purpose.

Exit fullscreen mode

Here we drop entries and transfers table before dropping the accounts table because there’s a foreign key constraint in entries and transfers that references accounts records.

OK, so now our migration scripts are ready. Let’s try to run them.

Check postgres container status

But before that, we should check if our postgres container is still running or not:

Exit fullscreen mode

By the way, I’m gonna show you some more docker commands to work with containers. If we want to stop a running container, we use docker stop with the container name or ID.

Exit fullscreen mode

After this, if we run docker ps , we won’t see the postgres container anymore because it’s not running. To list all containers, regardless of their running status, we can run:

Exit fullscreen mode

Now we see our postgres container with status exited .

To turn it back on, We just need to run: docker start and pass in the container name or ID.

Exit fullscreen mode

Then here we go, the postgres12 container is now up and running.

Access postgres container shell

We can access its shell with the docker exec command. As we’re using postgres alpine image, we don’t have /bin/bash shell as in ubuntu, so we use /bin/sh shell instead:

Exit fullscreen mode

Inside the shell, we have access to all standard linux commands.

And since this is a postgres container, it also gives us some CLI commands to interact with postgres server directly from the shell.

Create/drop database inside postgres container

We have to create the database before we can run the 1st migration.

So let’s run the createdb command inside the postgres container’s shell to create a new database for our Simple Bank:

Exit fullscreen mode

• We use the —username option to say that we’re connecting as root user.
• And the —owner option to say that the database we’re going to create will belong to root user as well.
• The last argument is the database name: simple_bank .

OK, the database is created. We can access its console with the psql command.

We can also delete the database using dropdb command and pass in the name of the database.

Exit fullscreen mode

We use exit command to get out of the container shell.

Create/drop database outside postgres container

Now from outside of the container, we can also run createdb directly with the docker exec command.

Exit fullscreen mode

And access the database console without going through the container shell.

Exit fullscreen mode

Write Makefile

OK, now I’m gonna create a Makefile in our project, then add a createdb command to create the simple bank database, and a dropdb command to delete it.

When working in a team, these commands will be useful for your team mates to easily setup the project on their local machine for development.

Let’s add the command that we used to start postgres container in the previous lecture to the Makefile as well.

Exit fullscreen mode

Alright, Now let’s stop the current postgres container.

Exit fullscreen mode

The container is stopped. I’m gonna remove it completely using docker rm command.

Exit fullscreen mode

Now when we run

Exit fullscreen mode

A new postgres container will be started. And we can run

Exit fullscreen mode

to create the simple_bank database.

View database with TablePlus

OK, the database is created. Let’s connect to it using TablePlus.

The connection that we’ve setup in the previous lecture will bring us to the root database. We can click on the database icon to open our new simple_bank database.

Alright, now you can see 2 databases here: root and simple_bank . For now the simple_bank database is empty. So let’s go back to the terminal and run the first migration.

Run the migration

Start with migrate . Then we use the -path option to specify the folder contains our migration files, which is db/migration .

Exit fullscreen mode

The -database option is used to specify the URL to the database server.

• We’re using postgres, so the driver name is postgresql .
• Then the username is root
• The password is secret
• The address is localhost , port 5432 .
• And the database name is simple_bank .

We use -verbose option to ask migrate to print verbose logging.

And finally we use the up argument to tell migrate to run migrate up command.

Oh, we’ve got an error: SSL is not enabled on the server. That’s because our postgres container doesn’t enable SSL by default.

So we should add sslmode=disable parameter to the database URL. Now run this command:

Exit fullscreen mode

And the migration is successful!

If we refresh the simple bank database in TablePlus, we can now see 4 tables: accounts , entries , transfers , and schema_migrations .

The schema_migrations table stores the latest applied migration version, which in our case is version 1, because we have run only 1 single migration file.

The dirty column tells us if the last migration has failed or not. If it fails, we must manually fix the issues to make the database state clean before trying to run any other migration versions.

Add migrate up/down to the Makefile

OK, now I’m gonna add the migrate up and migrate down command to the Makefile:

Exit fullscreen mode

Now let’s try them in the terminal! First I will run:

Exit fullscreen mode

And go back to TablePlus and refresh.

All tables are gone, except for the schema_migrations table.

OK, now let’s run:

Exit fullscreen mode

Then refresh TablePlus.

All tables are back again. Excellent!

So that wraps up today’s lecture about database migration. Thank you for reading and see you in the next lecture!

If you like the article, please subscribe to our Youtube channel and follow us on Twitter for more tutorials in the future.

If you want to join me on my current amazing team at Voodoo, check out our job openings here. Remote or onsite in Paris/Amsterdam/London/Berlin/Barcelona with visa sponsorship.

Источник

Была ли эта страница полезной?

0 / 5 — 0 рейтинги