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

merging changes between branches #406

Merged
merged 8 commits into from
Nov 23, 2017
Merged

merging changes between branches #406

merged 8 commits into from
Nov 23, 2017

Conversation

drujensen
Copy link
Member

Description of the Change

Merging branches between Elias and my PR's

Elias J. Perez and others added 2 commits November 18, 2017 15:44
Currently database settings reside in the config/database.yml this is
redundant since Amber has settings per environment.

This PR removes the `config/database.yml` and uses the environment yamls
files to load the database settings.

There is a couple of benefits for doing this:
1. Database settings are loaded per environment.
2. It is more intuitive to know where to put DB settings.

[ENV LOADER] Add database settings to environment_loader

- Adds database property to Amber::Settings
- Adds database property to spec test.yml
- Load database settings from environment yml
- Updates settings specs to check for database settings
- Updates environment loader specs to check for database settings

[CLI] Updates init spec file

- Updates amber spec file to check for database key
- Tidy init_spec connection string validation
- Add `expected_db_url(db_key, env)` method to cleanup specs
@drujensen drujensen requested a review from eliasjpr November 21, 2017 00:54
@drujensen drujensen changed the base branch from ep/move-db-settings-to-environments to master November 21, 2017 01:00
@drujensen drujensen changed the base branch from master to ep/move-db-settings-to-environments November 21, 2017 01:02
@drujensen
Copy link
Member Author

So happy! Just did some testing:

$AMBER_ENV=test amber db create migrate
Created database blog_test
Migrating db, current version: 0, target: 20171120170805106
OK   20171120170507644_create_user.sql
OK   20171120170716450_create_post.sql
OK   20171120170805106_create_comment.sql

Also:

$AMBER_ENV=test crystal spec
200  | GET  "/comments"  | 2.06ms
Params: {}
.200  | GET  "/comments/1"  | 4.59ms
Params: {"id" => "1"}
.200  | GET  "/comments/new"  | 1.79ms
Params: {}
.200  | GET  "/comments/1/edit"  | 872.0µs
Params: {"id" => "1"}
. | POST  "/comments"  | 766.0µs
Params: {"user_id" => "1", "post_id" => "1", "body" => "Fake"}
. | PATCH  "/comments/1"  | 1.2ms
Params: {"user_id" => "1", "post_id" => "1", "body" => "Fake", "id" => "1"}
. | DELETE  "/comments/1"  | 952.0µs
Params: {"id" => "1"}
.200  | GET  "/posts"  | 341.0µs
Params: {}
.200  | GET  "/posts/1"  | 515.0µs
Params: {"id" => "1"}
.200  | GET  "/posts/new"  | 955.0µs
Params: {}
.200  | GET  "/posts/1/edit"  | 817.0µs
Params: {"id" => "1"}
. | POST  "/posts"  | 761.0µs
Params: {"user_id" => "1", "title" => "Fake", "body" => "Fake", "published" => "true"}
. | PATCH  "/posts/1"  | 974.0µs
Params: {"user_id" => "1", "title" => "Fake", "body" => "Fake", "published" => "true", "id" => "1"}
. | DELETE  "/posts/1"  | 822.0µs
Params: {"id" => "1"}
.

Finished in 248.28 milliseconds
14 examples, 0 failures, 0 errors, 0 pending

@drujensen
Copy link
Member Author

@amberframework/core-team Can we get another approval? thx!

Currently database settings reside in the config/database.yml this is
redundant since Amber has settings per environment.

This PR removes the `config/database.yml` and uses the environment yamls
files to load the database settings.

There is a couple of benefits for doing this:
1. Database settings are loaded per environment.
2. It is more intuitive to know where to put DB settings.

[ENV LOADER] Add database settings to environment_loader

- Adds database property to Amber::Settings
- Adds database property to spec test.yml
- Load database settings from environment yml
- Updates settings specs to check for database settings
- Updates environment loader specs to check for database settings

[CLI] Updates init spec file

- Updates amber spec file to check for database key
- Tidy init_spec connection string validation
- Add `expected_db_url(db_key, env)` method to cleanup specs
@eliasjpr eliasjpr force-pushed the ep/move-db-settings-to-environments branch from f3f15bd to 2eb329d Compare November 23, 2017 15:16
@eliasjpr eliasjpr changed the base branch from ep/move-db-settings-to-environments to master November 23, 2017 15:16
Copy link
Contributor

@faustinoaq faustinoaq left a comment

Choose a reason for hiding this comment

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

👍


Then:

```shellsession
shards update
amber migrate up
amber db drop create migrate
Copy link
Contributor

Choose a reason for hiding this comment

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

@drujensen Is this valid for sqlite too?

Copy link
Member Author

Choose a reason for hiding this comment

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

Actually, it's incorrect for all db's. I will remove the drop.

If a model or migration is not created, all three should fail gracefully.

@drujensen drujensen merged commit 8953409 into master Nov 23, 2017
@drujensen drujensen deleted the dj/merge-branches branch November 23, 2017 18:20
@@ -10,15 +10,16 @@ describe Amber::Server do
@log = ::Logger.new(STDOUT).tap{|l| l.level = ::Logger::INFO}
@color = true
@redis_url = "\#{ENV[%(REDIS_URL)]? || %(redis://localhost:6379)}"
@database_url = "mysql://root@localhost:3306/amber_test_app_test"
Copy link
Member

Choose a reason for hiding this comment

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

I seriously think that database_url should be in secrets since a database isn't required to run amber, or someone might want to have multiple database connections. Secrets is perfect for this since you could do database_url, logging_database_url, kelly_blue_book_database_url

@drujensen
Copy link
Member Author

@elorest It seems to me that redis_url and database_url should be in the same place. I'm ok with moving both of them to secrets or leaving both of them where they are.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants