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

Only apply DATABASE_URL for Rails.env #14633

Merged
merged 12 commits into from
Apr 8, 2014

Conversation

matthewd
Copy link
Member

@matthewd matthewd commented Apr 7, 2014

As we like ENV vars, also support DATABASE_URL_#{env}, for more obscure use cases.

This needs more tests:

  • There's nothing about the 'DATABASE_URL_FOO' handling
  • And nothing showing that a normally-configured "foo" is unaffected by the DATABASE_URL (unless our current env is called 'foo')

Also, the config method could probably look substantially less awful.
#14616 // @rafaelfranca

rafaelfranca added a commit to rafaelfranca/omg-rails that referenced this pull request Apr 7, 2014
@rafaelfranca
Copy link
Member

@rafaelfranca rafaelfranca added this to the 4.1.0 milestone Apr 7, 2014
matthewd and others added 9 commits April 8, 2014 15:14
As we like ENV vars, also support DATABASE_URL_#{env}, for more obscure
use cases.
This seems to simplify the operative part. Most importantly, by
pre-loading all the configs supplied in ENV, we ensure the list is
complete: if the developer specifies an unknown config, the exception
includes a list of valid ones.
If the supplied string doesn't contain a colon, it clearly cannot be a
database URL. They must have intended to do a key lookup, so even though
it failed, give the explanatory deprecation warning, and raise the
exception that lists the known configs.

Conveniently, this also simplifies our logical behaviour: if the string
matches a known configuration, or doesn't contain a colon (and is
therefore clearly not a URL), then we output a deprecation warning, and
behave exactly as we would if it were a symbol.
.. even when the supplied config made no hint that name was relevant.
@matthewd
Copy link
Member Author

matthewd commented Apr 8, 2014

It's feeling like, now that DATABASE_URL doesn't mean override-everything, it should actually get priority over a 'url' key in the hash. I think the previous formulation was basically just a solution to the fact that otherwise, there was no way to avoid it applying to everything.

So, I think the search should go:

  • DATABASE_URL / DATABASE_URL_FOO
  • config['url']
  • config['database'] & friends

My justification is two-pronged: firstly, it seems more reasonable that the runtime environment can override the on-disk config, rather than the other way around; secondly, that sounds like a much simpler fallback process to document clearly. 😁

With my current version, changing that would involve swapping ||= for = on this line.

(This might be a bad idea because of how it interacts with people using <%= ENV['DATABASE_URL'] %> in database.yml.)

@rafaelfranca
Copy link
Member

I prefer to keep url with priority and my justification is: in the future I want to remove DATABASE_URL.

New generated applications already comes with this configuration:

production:
  url: <%= ENV['DATABASE_URL'] %>

In Rails 5 I want this to be the only way to configure the database. It still provides the flexibility of runtime override but doesn't require a lot of code to merge configurations.

The "DATABASE_URL_*" idea was moving in the wrong direction.

Instead, let's deprecate the situation where we end up using
ENV['DATABASE_URL'] at all: the Right Way is to explicitly include it in
database.yml with ERB.
In passing, allow multi-word adapters to be referenced in a URL:
underscored_name must become hyphened-name.
actual = resolve(:production, config)
expected = { "adapter"=>"postgresql", "database"=>"foo", "host"=>"localhost" }
expected = { "adapter"=>"not_postgres", "database"=>"not_foo", "host"=>"localhost" }
Copy link
Member

Choose a reason for hiding this comment

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

Now I'm confused. Should not this be using DATABASE_URL?

Copy link
Member

Choose a reason for hiding this comment

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

Duh! I'm really confused, only if :production were the current environment.

rafaelfranca added a commit that referenced this pull request Apr 8, 2014
Only apply DATABASE_URL for Rails.env
@rafaelfranca rafaelfranca merged commit 75e0ee8 into rails:master Apr 8, 2014
rafaelfranca added a commit that referenced this pull request Apr 8, 2014
Only apply DATABASE_URL for Rails.env
rafaelfranca added a commit that referenced this pull request Apr 8, 2014
Only apply DATABASE_URL for Rails.env
ENV['DATABASE_URL'] = "postgres://localhost/foo"
config = { "not_production" => { "adapter" => "not_postgres", "database" => "not_foo" } }
assert_raises AdapterNotSpecified do
spec("production", config)
resolve(:production, config)
Copy link
Member

Choose a reason for hiding this comment

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

Looks like we're testing to ensure the behavior in this PR does not work https://github.com/rails/rails/pull/14152/files#diff-9e1f52d3449a7a0cfdbd3a7afb5d905bR20

:production is the current env, and there's a valid DATABASE_URL, so we shouldn't get a raise here. Or am I missing something?

Copy link
Member

Choose a reason for hiding this comment

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

The current environment on these tests is called default_env. This is why production is raising.

Copy link
Member

Choose a reason for hiding this comment

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

Great! Thanks for the explanation, that makes sense then.

@schneems
Copy link
Member

I like that this PR cleaned up quite a bit of code I wasn't proud of. Scoping DATABASE_URL to only the current environment is a very elegant solution that makes quite a bit of sense. Sorry for the delay in the review, thanks for the work all ❤️

@matthewd matthewd deleted the narrow_database_url branch August 22, 2015 19:33
production:
url: <%%= ENV["DATABASE_URL"] %>

Choose a reason for hiding this comment

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

@matthewd @schneems Found this PR which removed ENV["DATABASE_URL"] from production configuration :)

Choose a reason for hiding this comment

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

@schneems I was referring to this comment in our discussion - #14633 (comment)

Copy link
Member Author

Choose a reason for hiding this comment

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

🙈

Copy link
Member

Choose a reason for hiding this comment

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

Lol. Glad we caught up in person. We can re-add the DATABASE_URL generation in config/database.yml. I'm still worried about it being taken out (again).

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.

None yet

4 participants