This fixes an exception when generating a new app on Ruby 2.8. Before
this commit, I get this exception:
```
$ be ruby railties/exe/rails new ~/git/fix-bug --dev
...
...
Traceback (most recent call last):
31: from railties/exe/rails:10:in `<main>'
30: from railties/exe/rails:10:in `require'
29: from /Users/aaron/git/rails/railties/lib/rails/cli.rb:18:in `<top (required)>'
28: from /Users/aaron/git/rails/railties/lib/rails/command.rb:45:in `invoke'
27: from /Users/aaron/git/rails/railties/lib/rails/command/base.rb:69:in `perform'
26: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
25: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
24: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
23: from /Users/aaron/git/rails/railties/lib/rails/commands/application/application_command.rb:26:in `perform'
22: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
21: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/group.rb:232:in `dispatch'
20: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/invocation.rb:134:in `invoke_all'
19: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/invocation.rb:134:in `map'
18: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/invocation.rb:134:in `each'
17: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/invocation.rb:134:in `block in invoke_all'
16: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
15: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
14: from (eval):1:in `run_webpack'
13: from /Users/aaron/git/rails/railties/lib/rails/generators/app_base.rb:419:in `run_webpack'
12: from /Users/aaron/git/rails/railties/lib/rails/generators/actions.rb:255:in `rails_command'
11: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/actions.rb:197:in `in_root'
10: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/actions.rb:187:in `inside'
9: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/2.8.0/fileutils.rb:139:in `cd'
8: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/2.8.0/fileutils.rb:139:in `chdir'
7: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/actions.rb:187:in `block in inside'
6: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/actions.rb:197:in `block in in_root'
5: from /Users/aaron/git/rails/railties/lib/rails/generators/actions.rb:256:in `block in rails_command'
4: from /Users/aaron/git/rails/activesupport/lib/active_support/core_ext/kernel/reporting.rb:15:in `silence_warnings'
3: from /Users/aaron/git/rails/activesupport/lib/active_support/core_ext/kernel/reporting.rb:28:in `with_warnings'
2: from /Users/aaron/git/rails/activesupport/lib/active_support/core_ext/kernel/reporting.rb:15:in `block in silence_warnings'
1: from /Users/aaron/git/rails/railties/lib/rails/generators/actions.rb:257:in `block (2 levels) in rails_command'
/Users/aaron/git/rails/railties/lib/rails/command.rb:31:in `invoke': wrong number of arguments (given 3, expected 1..2) (ArgumentError)
```
After this commit, things seem to work.
Putting ".localhost" at the end causes 4 IPAddr::InvalidAddressError
exceptions to be raised and rescued during every request when the
HostAuthorization middleware attempts to compare an IPAddr with a
"localhost" string.
This method was jumping through extra hoops to find the name of the
class the connection is stored on when we can get it from the connection
itself. Since we already have the connection we don't need to loop through the
pools.
In addition, this was using the wrong class name. The class name for the
schema migration should come from the connection owner class, not from
the `db_config.name`. In this case, `db_config.name` is the name of the
configuration in the database.yml. Rails uses the class name to lookup
connections, not the db config name, so we should be consistent here.
While working on this I noticed that we were generating an extra schema
migration class for `ActiveRecord::Base`. Since `ActiveRecord::Base` can
and should use the default and we don't want to create a new one for
single db applications, we should skip creating this if the spec name is
`ActiveRecord::Base`. I added an additional test that ensures the class
generation is correct.
If I had had these tests previously I would have not created PR #38658
and then promptly realize I needed to revert it.
We need to load and parse the configurations twice. Once before the
environment is loaded to create the named tasks and once after the
environment is loaded to have the real configurations. The configs
loaded before the env have the ERB stripped out and aren't valid
configs.
This adds a StringInquirer subclass EnvironmentInquirer that
predefines the three default environments as query methods, in
order to avoid dispatching through `method_missing` for every call
to those methods. The original StringInquirer was not modified due
to the side effects of having new env-related methods on it. This
new class was not implemented using lazy method definition to
avoid the open-ended possibility of defining a new method for all
query calls. The three default environments should cover a high
percentage of real-world uses, and users with custom environments
could add their own to this class.
Fixes#37803.
Currently the `rails new` generator supports options `—dev` and `—edge`.
`—dev` points to one’s local rails setup and `--edge` points to the latest stable Rails branch.
However, in the Rails community we often think of the ‘edge’ as the latest merged master. We can see as much in Shopify’s fantastic article showing how they point to the latest master version of Rails: https://engineering.shopify.com/blogs/engineering/living-on-the-edge-of-rails
I would originally have recommended changing ‘edge’ to point to master, as it has tripped me up on numerous occasions now.
However I would rather add the desired functionality then change the current edge functionality.
Therefore this PR adds the `—master` flag.
It is intended to do exactly as `edge` does, simply with the changethat it points to Rails’ master branch instead of latest stable (i.e. 6_0_stable)
Whenever developers see a new feature in Rails, such as the recently committed horizontal sharding (which prompted my PR), we would love to spin up a new Rails App to try out these new features.
This command would allow us to jump right in with no configuration and offer our testing of the features, even those of us who aren’t able to spend a lot of time on OSS support.
I have so. many. regrets. about using `spec_name` for database
configurations and now I'm finally putting this mistake to an end.
Back when I started multi-db work I assumed that eventually
`connection_specification_name` (sometimes called `spec_name`) and
`spec_name` for configurations would one day be the same thing. After
2 years I no longer believe they will ever be the same thing.
This PR deprecates `spec_name` on database configurations in favor of
`name`. It's the same behavior, just a better name, or at least a
less confusing name.
`connection_specification_name` refers to the parent class name (ie
ActiveRecord::Base, AnimalsBase, etc) that holds the connection for it's
models. In some places like ConnectionHandler it shortens this to
`spec_name`, hence the major confusion.
Recently I've been working with some new folks on database stuff and
connection management and realize how confusing it was to explain that
`db_config.spec_name` was not `spec_name` and
`connection_specification_name`. Worse than that one is a symbole while
the other is a class name. This was made even more complicated by the
fact that `ActiveRecord::Base` used `primary` as the
`connection_specification_name` until #38190.
After spending 2 years with connection management I don't believe that
we can ever use the symbols from the database configs as a way to
connect the database without the class name being _somewhere_ because
a db_config does not know who it's owner class is until it's been
connected and a model has no idea what db_config belongs to it until
it's connected. The model is the only way to tie a primary/writer config
to a replica/reader config. This could change in the future but I don't
see value in adding a class name to the db_configs before connection or
telling a model what config belongs to it before connection. That would
probably break a lot of application assumptions. If we do ever end up in
that world, we can use name, because tbh `spec_name` and
`connection_specification_name` were always confusing to me.
Follow-up to #38463.
By isolating ARGV, we guard against commands inadvertently depending on
prior ARGV contents. Any such command will now behave consistently when
run via `Rails::Command.invoke`, whether coming from the Rails CLI or
from library code. Likewise, any ARGV mutations done by a command will
not affect code that executes after `Rails::Command.invoke`.
A .ruby-version file is not useful in a plugin dummy app because the
plugin itself dictates the required Ruby version. Indeed, the dummy app
.ruby-version file might fall out of sync with whatever the plugin
dictates, and thus result in unexpected "Could not find gem" errors when
running commands from within the dummy app directory.
Follow-up to #38429.
`Rails::Command.invoke` passes arguments through to the appropriate
command class. However, some command classes were ignoring those
arguments, and instead relying on the contents of ARGV. In particular,
RakeCommand expected ARGV to contain the arguments necessary to the Rake
task, and no other arguments. This caused the `webpacker:install` task
to fail when the `--dev` option from `rails new --dev` remained in ARGV.
This commit changes the relevant command classes to not rely on the
previous contents of ARGV. This commit also adds a missing `require`
for use of `Kernel#silence_warnings`.
Fixes#38459.
When is use a scaffold_controller add the routes as resources to the
config/route.rb
Also enable to use --skip-routes if doesn't want include the resources
into the config/routes.rb file.
The schema cache tests test the following scenarios:
1) The default case works (single db, primary spec name (dev is default
to primary in 2-tier config), standard default schema cache filename)
2) Primary always wins over other entries
3) A custom schema cache filename works when set in the configuration
4) A custom schema cache filename works when set in the ENV
Cases that don't work:
1) A non-primary database entry picks up a namespaced schema cache file
This can't work currently because there's no way of knowing which cache
we actually want. In this railtie we can only load ActiveRecord::Base's
schema cache. If we grab the first config we risk loading a cache for
another connection because order is not guaranteed.
2) Multi-db schema caches
The reasons are similar to above. In addition we can't loop through the
configs, establish a connection, and load the cache because we don't
know what parent class to establish a connection to. In that case AR
Base will always get the cache and it would cause the last one to win
and therefore be loaded on the wrong connection.
The real fix for these issues is to get rid of the railtie entirely, but
for now we needed to set this back to what the behavior was before
recent changes but with the ability to pass a custom key.
Co-authored-by: Katrina Owen <kytrinyx@github.com>
The documentation for Rails::Generators::TestCase suggests using tmp/ as
the destination directory when testing generators. Many plugins test
generators, so it makes sense to include tmp/ in the default .gitignore.
Rails has a number of places where a YAML configuration file is read,
then ERB is evaluated and finally the YAML is parsed.
This consolidates that into one common class.
Co-authored-by: Kasper Timm Hansen <kaspth@gmail.com>
If the plugin or one of its dependencies requires a version of Rake
that is different than the version executing the Rakefile,
`require 'bundler/setup'` will raise a LoadError with a helpful error
message like: "You have already activated rake 13.0.1, but your Gemfile
requires rake 12.3.3. Prepending `bundle exec` to your command may solve
this."
If that LoadError is swallowed, another LoadError will eventually be
raised with a less helpful / more confusing error message like: "cannot
load such file -- rake".
