| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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'
```
|
|
|
|
|
|
|
|
| |
This prevents Rails from assigning meaningless log levels to third
party loggers like log4r. If `Rails.logger` is not `kind_of?(::Logger)`
we simply assign the `config.log_level` as is.
This bug was introduced by #11665.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|\
| |
| | |
Move Rack::Cache after ActionDispatch::Static in the middleware stack
|
| | |
|
|/ |
|
|
|
| |
Fix bug when log level of Rails.logger (which was set via config.logger) does not match the config.log_level.
|
|
|
|
|
|
|
|
| |
Showing welcome page in production can expose information, which should
not be visible on production if people don't override the default root
route.
This reverts commit b0caea29c2da9f4c8bb958019813482da297067d.
|
|
|
|
|
|
|
| |
With Rails 4 the default index page was moved from a static file `index.html` inside the `public/` folder to an internal controller/view inside of the railties gem. This was to allow use of erb in the default index page and to remove the requirement that new apps must delete a static file to make their index pages work. While this was a good change, the functionality was unexpected to developers who wish to get their apps running in production ASAP. They will create a new app `rails new my app`, start a server to verify it works, then immediately deploy the app to verify that it can start working in production. Unfortunately locally they see a page when they visit `localhost:3000` when they visit their production app they get an error page.
We initially anticipated this problem in the original pull request, but did not properly anticipate the severity or quantity of people who would like this functionality. Having a default index page serves as an excellent litmus test for a passed deploy on default apps, and it is very unexpected to have a page work locally, but not on production.
This change makes the default index page available in production if the developer has not over-written it by defining their own `root` path inside of routes.
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 19ac034bdc9be175eff7cf54208ba14b43d97681.
And allows webservers to configure X-Sendfile-Type.
Closes #11440 thanks to [@MSch]
Conflicts:
railties/lib/rails/application.rb
|
| |
|
| |
|
|
|
|
|
|
|
| |
A lot of logic for building the default middleware stack is currently
kept in Application class, but this can be encapsulated and made more
modular by being moved to its own class. Also refactored a couple of the
helper methods.
|
| |
|
|
|
|
|
| |
Conflicts:
railties/test/application/loading_test.rb
|
|
|
|
|
|
| |
This reverts commit b7d9d6e2cd5082d269dafbc0316e2107febe1451.
Per discussion with @jeremy and @rubys on Campfire.
|
| |
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Whilst autoloading is known to be not threadsafe, leaving it in place
is a softer solution than failing hard when an application is deployed.
Many older applications will have paths added to `autoload_paths` and
ideally these should be eagerly loaded to be threadsafe. However one
of these paths is quite often lib which could lead to unintended
consequences due to the 'junk drawer' nature of this directory.
Developers should refrain from adding paths to `autoload_paths` or
`eager_load_paths` and use custom folders inside app for code that
needs to be eagerly loaded and use `require` or `require_dependency`
to explicitly load code from other locations.
|
| |
|
|
|
|
| |
with Rails 4.0.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an alternative implementation to #7771 thanks to the advice of @spastorino
Rails is a dynamic framework that serves a static index.html by default. One of my first questions ever on IRC was solved by simply deleting my public/index.html file. This file is a source of confusion when starting as it over-rides any set "root" in the routes yet it itself is not listed in the routes. By making the page dynamic by default we can eliminate this confusion.
This PR moves the static index page to an internal controller/route/view similar to `rails/info`. When someone starts a rails server, if no root is defined, this route will take over and the "dynamic" index page from rails/welcome_controller will be rendered. These routes are only added in development. If a developer defines a root in their routes, it automatically takes precedence over this route and will be rendered, with no deleting of files required.
In addition to removing this source of confusion for new devs, we can now use Rails view helpers to build and render this page. While not the primary intent, the added value of "dogfooding" should not be under-estimated.
The prior PR #7771 had push-back since it introduced developer facing files. This PR solves all of the same problems, but does not have any new developer facing files (it actually removes one).
cc/ @wsouto, @dickeyxxx, @tyre, @ryanb, @josevalim, @maxim, @subdigital, @steveklabnik
ATP Railties and Actionpack.
|
| |
|
|
|
|
|
| |
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`.
|