Recently I’ve been using golang-migrate for database change management, and according to the official tutorial, I need to download a local binary first and generate the change file on the command line.
This will generate a bunch of
.sql files under
. /db/migrations, where
000011 is the number, incremented from
create_article_table is the incoming file name,
.up.sql represents the SQL executed when changing forward, and
.down.sql represents the SQL executed when rolling back. SQL.
We can change the database locally like this after editing.
But in practice, after we publish the project, if we have to go online to change it every time, it will be more troublesome, can we let the code run itself? Of course you can.
Automatic code execution of changes
migrate can be invoked both from the command line and as a library. migrate supports a variety of sources such as
s3 and so on.
The one I want to use is the official
embed, which migrate wraps as
That is, immediately after the application is started, the database is initialized and database changes are started immediately after connecting to the database. Look at the top
var fs embed.FS and the comment on the top line. This is the official Go way of packaging files into binary, essentially reading the contents of the file at compile time, compiling it, and assigning it to the
This allows you to make database changes automatically after each startup before you start executing the code. However, it’s worth noting that it’s best to deploy only one copy of the program that runs the database changes, otherwise there will be competition problems.
This article has documented the way I use migrate, which is more convenient than executing all operations at the command line and eliminates the need to synchronize sql files to the server, but the downside is that the binary file will become larger. There are pros and cons, but I prefer this approach.