Run only the next migration file - migrate

Is it possible to run only the next migration file with the sequelize-cli?
I have been looking through the docs and help-section of the cli, and it does not appear to be such a feature.
For instance, I have the following when running the sequelize db:migrate:status command;
Loaded configuration file "config/config.js".
Using environment "development".
up 20170301090141-create-something.js
up 20170301133113-create-else.js
up 20170301133821-Update-some-stuff.js
up 20170301135339-create-some-model.js
up 20170307152706-update-some-stuff-two.js
down 20170316142544-create-an-index.js
down 20170421112638-do-some-refactor.js
I would like to only run the 20170316142544-create-an-index.js.
Of course, I can remove all the relevant files. Then I add each migration back one-by-one, running "all" migrations between each one. But this seems so barbaric.

I came here from Google and was not able to find any options in doc. However, the CLI sequelize-cli db:migrate --help shows an option to select a range of migrations you want to run.
They are:
--to Migration name to run migrations until
--from Migration name to start migrations from (excluding)
Apparently, you need to provide the exact filename not the migration name. (Found in source code)
TLDR:
npx sequelize-cli db:migrate --from will-not-be-included.js --to filename.js

I think the question was already answered, but some people still getting confused. I will try to give a straight answer for this specific question:
npx sequelize-cli db:migrate --to 20170316142544-create-an-index.js
In this specific case there's no need to add the option --from, because 20170316142544-create-an-index.js is the next migration to be applied.
But if the question was:
I would like to only run the 20170421112638-do-some-refactor.js
Then you would have to use the option --from to jump all the other migrations until the desired one. In this case:
npx sequelize-cli db:migrate --from 20170316142544-create-an-index.js --to 20170421112638-do-some-refactor.js

The things is, Sequelize only executes those migrations which are not executed yet, Means which is pending.
It means when you run command sequelize:migrate it will only executes those who is still pending.

I think you maked all models and afther that you're trying to run the migrations.
So, I found one solution, i don't know if this is good idea. Sequelize names the migration files with instant actual date. So ,if you change the first string of name for the other wanted file, e.i.
20190717191628-create-team.js
20190717191909-create-player.js
**for**
20190717191909-create-team.js
20190717191628-create-player.js
After that,order all files like you want , and run the db:migrate command.

You can simply change the sequence of files in the migrations folder. As the filename always starts with timestamp so in order to change the sequence of migrations you just need to update the timestamp accordingly by renaming the file.
20170316142544-create-an-index.js. just see which migration ran latest and add rename this migration timestamp with the timestamp just next to the one that executed. add some typos in other ones after it or move them out of the folder for a second and then migrate.

Related

npx typeorm migration:create -n TestData Dosen't create a migration

enter image description here
I wasn't able to create a migration even after following doc.
Since the update (I don't know which, exactly), the flag -n was replaced by -o.
So, now you need to run.
typeorm migration:create -o path/to/my/migration
If you are using multiple datasources
migration:create doesn't work with specific datasources, so
I reccomend you to add two scripts in "scripts" session at package.json like the following:
default typeorm (that you will use for non-specific database stuff):
"typeorm": "ts-node-dev ./node_modules/typeorm/cli.js"
your custom typeorm (that you will use for your specific database stuff, like run & revert migrations):
"myTypeorm":"ts-node-dev ./node_modules/typeorm/cli.js -d path/to/my/ormconfig.ts"

Rails 5: How Do I Set Up a Merge Tool to use for rails app:update?

I'm upgrading a rails 5.2.4.1 app to rails 6. There are a few config files I want to merge instead of manually adding information from a copy of the old file.
The first time I entered m to merge the file I got the following message.
Please specify merge tool to `THOR_MERGE` env.
I did a search and found this blog post. The folder that this person found after Googling does not exist on my Mac computer.
FileMerge doesn't exist and DiffMerge is very old. I haven't found any information about using one with rails app:update.
What Mac merge tools are currently used that I can set the env var THOR_MERGE to?
Stumbled upon this answer searching for the same thing.
You can launch vscode diff tool by setting the THOR_MERGE env variable as follows:
THOR_MERGE="code -d $1 $2"
This is assuming you have code in your PATH, which you can setup by following the instructions here.
It seems that XCode includes /usr/bin/opendiff, which is a binary that launches FileMerge.app. So I was able to:THOR_MERGE=opendiff rails app:update
RubyMine can also be used as the merge tool. To make that work on my macOS Monterey system, I created a new Bash script at /usr/local/bin/rubymine-merge (based in part on the rubymine script provided by JetBrains Toolbox) with the following code:
#!/usr/bin/env bash
declare -- wait="-W"
bundle exec rubocop --server -A "$1"
open -na "$HOME/Library/Application Support/JetBrains/Toolbox/apps/RubyMine/ch-0/222.3739.56/RubyMine 2022.2 EAP.app/Contents/MacOS/rubymine" $wait --args merge "$2" "$1" "$2"
After this, I was able to invoke the Rails update script as follows:
THOR_MERGE=rubymine-merge bin/rails app:update
This is working as of RubyMine 2022.2.1 in mid-August of 2022.
The Rails update script seems to require that the merge tool behave as if it had received a --wait parameter, because after the last merge the script deletes all temporary files. Passing --wait as a command-line parameter seems problematic with the 2022.2 version of the command-line script, so I hard-coded the -W on line 3.
I also inserted a call to rubocop on line 5 so that the proposed changes from the Rails app:update script would already be aligned with the standards for this project. Skip that part if it's not meeting your needs. I had to use bundle exec rubocop instead of bin/rubocop because the Rails app:update script is not always running in the context of the root directory of your project.
It is suboptimal for this script be separate from the /usr/local/bin/rubymine script that is generated by JetBrains Toolbox. Every time a new version of RubyMine is installed, the path to the actual RubyMine application can change.
Simple Solution:
THOR_MERGE=kdiff3 rails app:update
or use opendiff / meld / kdiff etc.
Credit to #pduey (thanks).

TypeORM - run specific migration

I know typeorm migration:run to run all migration files, but some time I want run a file like insert file, or a modified file. But i can't find any doc for that. How to do that thanks.
This is not possible. You can see the docs of the migration with
typeorm migration:run -h
During development you can locally change your connection settings, e.g. change the path to the migration files in your ormconfig.json to match only your file.
"migrations": [
"src/db/migration/**/yourmigration.ts"
]
If you want to seed the database with data you shouldn't use migrations.
Migrations' purpose is to create the database's structure, This is why migrations are executed serially, therefore running a single migration non-serially misses the point.
For database seeding with typeorm you can use typeorm cli query, you can create a script that read the SQL from a file.
For example in a node.js app & bash:
package.json:
"scripts": {
...,
"typeorm": "npx ts-node -r tsconfig-paths/register ./node_modules/typeorm/cli --config ormconfig-migrations.ts",
"db:seed": "bash scripts/db-seed.sh"
}
db-seed.sh:
#!/bin/bash
query=""
for filename in sql/seed/*.seed.sql; do
query=${query}"$(< ${filename})";
done
npm run typeorm query "${query}";
Pay attention there is a bug in this solution, there is always an error thrown from the logger typeorm uses - ignore it. it doesn't relate to the db operation, and does not represent the success of the process.
A migration file that was shared with others shouldn't be modified, in this case, create a new migration.
If that file wasn't shared and is in development, you can run migration:revert as many as you need, then modify and run migration:run again.
For running a specific migration my solution is in ormconfig.js add:
module.exports = {
...
migrations: [process.env.DB_MIGRATION_DIR || 'src/database/migrations/*.ts'],
...
}
and now use DB_MIGRATION_DIR=path/to/migration.ts npm run typeorm migration:run run your specific migration
Another tip for force re-running a migration, but might need some customization for connection string variables - add in your package.json:
{
"scripts": {
...
"migration:rerun": "psql postgresql://$DB_USER#localhost:5432/$DB_NAME -c "delete from migrations where name like '%$SEED_NAME%';" && DB_MIGRATION_DIR='$DB_MIGRATION_DIR' npm run typeorm migration:run"
...
}
...
}
I dont think we can run any migration particular with cli, but we can run it through query runner. please refer the following code:
const connection: Connection = getConnection();
const queryRunner: QueryRunner = connection.createQueryRunner();
//createDatabase16413343434 is class/migration generated from cli
const createDatabase = new createDatabase16413343434();
await createDatabase.up(queryRunner);
One can write custom code to run one migration like inserting a record or just creating/ deleting a single table kind of things. typeorm provides "QueryRunner" which basically run queries in the background. So just create a file with the code given following code to write custom single migration
code to run migration

No command supplied, defaulting to serve Vapor

I want to create simple data base model. I'am using postgresql-provider package major:1 minor:1. I've followed instructions to create model. I've added preparations and resource to my Droplet object. Message I receive after running is
No command supplied, defaulting to serve...
Database prepared
Server 'default' starting at 0.0.0.0:8080
Can someone help me with the problem?
With regards to the message No command supplied, defaulting to serve, this is because the binary executable is expecting a 'command'.
vapor run [command]
.build/[configuration]/App [command]
There are a variety of commands available, such as vapor run prepare to run your database preparations, or vapor run serve to begin the HTTP server. You can even add your own commands.
When the executable is run without any commands, it assumes you meant to run the serve command, which is the meaning of your messsage No command supplied, defaulting to serve.
To suppress this, simply use vapor run serve or .build/[configuration]/App serve to run your Vapor project.
Notice how it said in the message Database prepared. That is because all the tables you've specified in your models already exist.
If you've made changes to your models, you'll first need to revert your changes. Vapor has a set of commands just for preparing a database.
vapor run prepare --revert
and
vapor run prepare
The --revert one will run whatever code you've put in the revert function on your models (usually people just delete the table), and then the other command will run the prepare functions and create your models' tables from scratch again.

Rails Capistrano Deploy Best Practices / Log Files

I have a rails app that I inherited. In deploy.rb, it performs the following commands:
run "mv #{shared_path}/log/#{rails_env}.log #{shared_path}/log/#{rails_env}_old"
run "touch #{shared_path}/log/#{rails_env}.log && chmod -R 777 #{shared_path}/log"
So you can see it's moving the existing log file to one called _old and then creating a new one.
This causes a problem when in some situations, the first deploy fails. When I deploy again, it overwrites the _old file a second time and now the previously existing logs are gone.
The thing is, that I don't understand why the deploy script is doing this. I don't understand why it was written like this in the first place. I believe everybody would be fine if we just left the log files alone during the deploy.
Does anybody have any clues for me?
Remove it, and use log rotate.
What the deploy script is doing is good because log files get big really soon and writing to big file is costly. You should use log rotate or some other utility. But if you want to keep it simple, give unique file names by appending timestamps
run "mv #{shared_path}/log/#{rails_env}.log #{shared_path}/log/#{rails_env}_old_#{Time.now.Time.now.to_i}"
run "touch #{shared_path}/log/#{rails_env}.log && chmod -R 777 #{shared_path}/log"

Resources