Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: added support for database migrations #91

Merged
merged 6 commits into from
Nov 1, 2020
Merged

Conversation

yann510
Copy link
Collaborator

@yann510 yann510 commented Oct 27, 2020

No description provided.

@yann510 yann510 force-pushed the 22-migration-support branch 2 times, most recently from 7947ae4 to 915afb5 Compare October 27, 2020 19:37
password: process.env.DATABASE_PASSWORD || "postgres",
database: process.env.DATABASE_NAME || "stator",

entities: [__dirname + "/../../../**/*.entity{.ts,.js}"],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use @stator/libs/models here instead of long path

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not supported by the compiler option I need to set for the migrations to work. :(

@@ -0,0 +1,18 @@
import { ConnectionOptions } from "typeorm"

const config: ConnectionOptions = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you added this but you're not using it in the app? also where is synchronize?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this file is used only when running the migration which it's path is specified in the npm script command. Locally migrations will be done automatically as they will be synchronized from the model. I'm not sure if that's the right approach though. Maybe we should have the same process locally as in production? We could run the migrations on API startup to ensure we're always up to date.

What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could. But my main concern is that we are duplicating the config here and in the api. We should use the same for both to avoid modification errors

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a very valid concern.
I had tried importing the configuration file from the API, but since I need to target commonJS, it doesn't support the paths provided in the tsconfig.base.json. One way this could work would be to flip things around where ormconfig.ts would be the source of truth, and the API configuration file would import the ormconfig.ts file properties.

Makes sense?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I agree with the swap

@coveralls
Copy link

coveralls commented Oct 28, 2020

Pull Request Test Coverage Report for Build 340441895

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 100.0%

Totals Coverage Status
Change from base Build 331349394: 0.0%
Covered Lines: 36
Relevant Lines: 36

💛 - Coveralls

@yann510 yann510 force-pushed the 22-migration-support branch 3 times, most recently from 4cad857 to bd67ea9 Compare November 1, 2020 17:10
README.md Outdated
@@ -211,6 +211,28 @@ To ensure your developers don't get into any trouble while installing those, the
**By default, the project uses postgres.**
If this is what you want, you're good to go; everything will work out of the box.

#### Migrations

By default, the automatic synchronization is activate between your models and the database.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is activate 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
By default, the automatic synchronization is activate between your models and the database.
By default, the automatic synchronization is activated between your models and the database.

README.md Outdated
```
npm run typeorm -- migration:generate -n {MIGRATION_NAME}
```
This will check the difference of models between your defined entities your database schemas.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This will check the difference of models between your defined entities your database schemas.
This will check the difference between models for your defined entities and your database schemas.

username: process.env.DATABASE_USERNAME || "postgres",
password: process.env.DATABASE_PASSWORD || "postgres",
database: process.env.DATABASE_NAME || "stator",
synchronize: !!process.env.DATABASE_SYNCHRONIZE || true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is never going to work. if you set it to false, it will fallback to true. you should use the ?? operator instead

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, good catch!

@yann510 yann510 merged commit 94bba7d into master Nov 1, 2020
@yann510 yann510 deleted the 22-migration-support branch November 1, 2020 17:55
@github-actions
Copy link
Contributor

github-actions bot commented Nov 1, 2020

🎉 This PR is included in version 1.11.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

@yann510 yann510 mentioned this pull request Nov 1, 2020
2 tasks
@yann510 yann510 linked an issue Nov 1, 2020 that may be closed by this pull request
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add migration support
3 participants