-
Notifications
You must be signed in to change notification settings - Fork 205
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
Conversation
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
So happy! Just did some testing:
Also:
|
@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
f3f15bd
to
2eb329d
Compare
2e32c7e
to
a86ea2d
Compare
There was a problem hiding this 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
@@ -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" |
There was a problem hiding this comment.
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
@elorest It seems to me that |
Description of the Change
Merging branches between Elias and my PR's