| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Since cc03675d30b58e28f585720dad14e947a57ff5b the error message became like
"Could not load database configuration. No such file -"
which doesn't really tell what's actually missing.
|
|
|
|
|
|
|
| |
If we want to always default to :debug, let's just do that.
At which point the production.rb entry can become an "uncomment to
change" instead.
|
|
|
|
|
|
|
|
|
|
| |
Previously setting simple values to the config.x object resulted in the
following:
config.x.super_debugger = true
config.x.super_debugger #=> {}
Which was against the examples showed in the changelog/release notes.
|
|
|
|
|
|
|
|
|
| |
This reverts commit de4891344ccc074f6d5693f4fac6ad610584e336.
Conflicts:
railties/lib/rails/railtie/configuration.rb
It added regression. Will be back after the beta
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Hashes can be assigned
2. We don't need a special level anymore
The method chain only works in the top level.
If users need a second level they need to assign a OrderedOptions to the
key:
config.resque.server = ActiveSupport::OrderedOptions.new
config.resque.server.url = "http://localhost"
config.resque.server.port = 3000
[Rafael Mendonça França + Carlos Antonio da Silva]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Database configuration was trying to load the first path that
config.paths['config/database'] was returning even if the path didn't
exist in the filesystem.
Because Rails::Paths::Path has the possibility to return more than 1
path (as an array), database_configuration should filter down the paths
to the existing one and then load the first one.
This would make it possible to move the database.yml file and add the
new path to paths['config/database'] and still load the configurations.
|
| |
|
|
|
|
| |
at config level
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now if there is an error retrieving database configuration the intent of the error (what the code was trying to do while you got the error) could be more explicit.
Instead of this error:
```
Invalid DATABASE_URL: nil
(erb):9:in `rescue in <main>'
(erb):6:in `<main>'
/Users/schneems/.rbenv/versions/2.1.0/lib/ruby/2.1.0/erb.rb:850:in `eval'
/Users/schneems/.rbenv/versions/2.1.0/lib/ruby/2.1.0/erb.rb:850:in `result'
/Users/schneems/Documents/projects/rails/railties/lib/rails/application/configuration.rb:98:in `database_configuration'
/Users/schneems/Documents/projects/rails/activerecord/lib/active_record/railtie.rb:41:in `block in <class:Railtie>'
/Users/schneems/Documents/projects/rails/railties/lib/rails/railtie.rb:237:in `instance_exec'
/Users/schneems/Documents/projects/rails/railties/lib/rails/railtie.rb:237:in `block in run_tasks_blocks'
/Users/schneems/Documents/projects/rails/railties/lib/rails/railtie.rb:237:in `each'
/Users/schneems/Documents/projects/rails/railties/lib/rails/railtie.rb:237:in `run_tasks_blocks'
/Users/schneems/Documents/projects/rails/railties/lib/rails/application.rb:339:in `block in run_tasks_blocks'
/Users/schneems/Documents/projects/rails/railties/lib/rails/engine/railties.rb:13:in `each'
```
I propose we issue this error:
```
Cannot load `Rails.application.database_configuration`:
Invalid DATABASE_URL: nil
(erb):9:in `rescue in <main>'
(erb):6:in `<main>'
/Users/schneems/.rbenv/versions/2.1.0/lib/ruby/2.1.0/erb.rb:850:in `eval'
/Users/schneems/.rbenv/versions/2.1.0/lib/ruby/2.1.0/erb.rb:850:in `result'
/Users/schneems/Documents/projects/rails/railties/lib/rails/application/configuration.rb:98:in `database_configuration'
/Users/schneems/Documents/projects/rails/activerecord/lib/active_record/railtie.rb:41:in `block in <class:Railtie>'
/Users/schneems/Documents/projects/rails/railties/lib/rails/railtie.rb:237:in `instance_exec'
/Users/schneems/Documents/projects/rails/railties/lib/rails/railtie.rb:237:in `block in run_tasks_blocks'
/Users/schneems/Documents/projects/rails/railties/lib/rails/railtie.rb:237:in `each'
/Users/schneems/Documents/projects/rails/railties/lib/rails/railtie.rb:237:in `run_tasks_blocks'
/Users/schneems/Documents/projects/rails/railties/lib/rails/application.rb:339:in `block in run_tasks_blocks'
/Users/schneems/Documents/projects/rails/railties/lib/rails/engine/railties.rb:13:in `each'
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently Active Record can be configured via the environment variable `DATABASE_URL` or by manually injecting a hash of values which is what Rails does, reading in `database.yml` and setting Active Record appropriately. Active Record expects to be able to use `DATABASE_URL` without the use of Rails, and we cannot rip out this functionality without deprecating. This presents a problem though when both config is set, and a `DATABASE_URL` is present. Currently the `DATABASE_URL` should "win" and none of the values in `database.yml` are used. This is somewhat unexpected to me if I were to set values such as `pool` in the `production:` group of `database.yml` they are ignored.
There are many ways that active record initiates a connection today:
- Stand Alone (without rails)
- `rake db:<tasks>`
- ActiveRecord.establish_connection
- With Rails
- `rake db:<tasks>`
- `rails <server> | <console>`
- `rails dbconsole`
We should make all of these behave exactly the same way. The best way to do this is to put all of this logic in one place so it is guaranteed to be used.
Here is my prosed matrix of how this behavior should work:
```
No database.yml
No DATABASE_URL
=> Error
```
```
database.yml present
No DATABASE_URL
=> Use database.yml configuration
```
```
No database.yml
DATABASE_URL present
=> use DATABASE_URL configuration
```
```
database.yml present
DATABASE_URL present
=> Merged into `url` sub key. If both specify `url` sub key, the `database.yml` `url`
sub key "wins". If other paramaters `adapter` or `database` are specified in YAML,
they are discarded as the `url` sub key "wins".
```
### Implementation
Current implementation uses `ActiveRecord::Base.configurations` to resolve and merge all connection information before returning. This is achieved through a utility class: `ActiveRecord::ConnectionHandling::MergeAndResolveDefaultUrlConfig`.
To understand the exact behavior of this class, it is best to review the behavior in activerecord/test/cases/connection_adapters/connection_handler_test.rb though it should match the above proposal.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Since the Rack::Lock still exists in development,
let's provide a way to disable it explicitly.
|
| |
|
|
|
| |
Better comment for database_configuration method
|
|
|
| |
Changed comment that referenced the property #database_configuration_file, now it's paths["config/database"]
|
|
|
|
|
|
|
| |
make connection_url_to_hash a class method
This als prevents loading database.yml if it doesn't exist
but DATABASE_URL does
|
| |
|
|
|
|
| |
with Rails 4.0.
|
| |
|
|
|
|
|
| |
Provides a better error message incase the database.yaml
has some errors.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
It's sometimes hard to quickly find where deprecated call was performed, especially in case of migrating between Rails versions. So this is an attempt to improve the call stack part of the warning message by providing caller explicitly.
|
| |
|
|\
| |
| |
| |
| | |
Conflicts:
railties/test/application/configuration_test.rb
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
| |
manifest path.
This option is now unsupported in sprockets-rails.
|
|
|
|
| |
option added (default is Monday)
|
| |
|
| |
|
|
|
|
|
|
| |
Tell people to install `activerecord-session_store` gem when it's not
installed instead ofraising `NameError` on missing
`ActionDispatch::Session::ActiveRecordStore`.
|
|
|
|
|
| |
This functionality will be available from gem
`active_record-session_store` instead.
|
| |
|
|
|
|
|
|
|
| |
The new option allows any Ruby namespace to be registered and set
up for eager load. We are effectively exposing the structure existing
in Rails since v3.0 for all developers in order to make their applications
thread-safe and CoW friendly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The flag was mainly used to add a Rack::Lock middleware to
the stack, but the only scenario the lock is desired is in
development.
If you are deploying on a not-threaded server, the Rack::Lock
does not provide any benefit since you don't have concurrent
accesses. On the other hand, if you are on a threaded server,
you don't want the lock, since it defeats the purpose of using
a threaded server.
If there is someone out there, running on a thread server
and does want a lock, it can be added to your environment
as easy as: `use Rack::Lock`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the eager load behavior was mostly coupled to
config.cache_classes, however this was suboptimal since in
some environments a developer may want to cache classes but
not necessarily load them all on boot (for example, test env).
This pull request also promotes the use of config.eager_load
set to true by default in production. In the majority of the
cases, this is the behavior you want since it will copy most
of your app into memory on boot (which was also the previous
behavior).
Finally, this fix a long standing Rails bug where it was
impossible to access a model in a rake task when Rails was
set as thread safe.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by Active Support)
Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in
https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d
we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.
In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.
|
| |
|