Addresses rails/rails#32247
Add test that checks identify and analyze work in correct order
Break out direct upload test helper
Review changes for direct-upload test helper
Not everything that responds to `routes` is a Rails engine - for example
a Grape API endpoint will have a `routes` method but can't be used with
`assert_recognizes` as it doesn't respond to `recognize_path_with_request`.
Fixes#32312.
Add a prefix option to ActiveRecord::Store.store_accessor and
ActiveRecord::Store.store. This option allows stores to have identical keys
with different accessors.
The rack gem returns PATH_INFO as an ASCII-8BIT encoded string but it
was being converted to US-ASCII by the match? method because it was
calling Rack::Utils.escape_path. To prevent incompatibile encoding
warnings use ASCII-8BIT strings for the root path and let Ruby handle
any filename encoding conversion.
Fixes#32294, Closes#32314.
Moves the configs_for and DatabaseConfig struct into it's own file. I
was considering doing this in a future refactoring but our set up forced
me to move it now. You see there are `mattr_accessor`'s on the Core
module that have default settings. For example the `schema_format`
defaults to Ruby. So if I call `configs_for` or any methods in the Core
module it will reset the `schema_format` to `:ruby`. By moving it to
it's own class we can keep the logic contained and avoid this
unfortunate issue.
The second change here does a double loop over the yaml files. Bear with
me...
Our tests dictate that we need to load an environment before our rake
tasks because we could have something in an environment that the
database.yml depends on. There are side-effects to this and I think
there's a deeper bug that needs to be fixed but that's for another
issue. The gist of the problem is when I was creating the dynamic rake
tasks if the yaml that that rake task is calling evaluates code (like
erb) that calls the environment configs the code will blow up because
the environment is not loaded yet.
To avoid this issue we added a new method that simply loads the yaml and
does not evaluate the erb or anything in it. We then use that yaml to
create the task name. Inside the task name we can then call
`load_config` and load the real config to actually call the code
internal to the task. I admit, this is gross, but refactoring can't all
be pretty all the time and I'm working hard with `@tenderlove` to
refactor much more of this code to get to a better place re connection
management and rake tasks.
Somehow `test_config_another_database` didn't fail on CI, but it will
fail locally.
https://travis-ci.org/rails/rails/jobs/356212950#L2474-L2482
```
% bundle exec ruby -w -Itest test/generators/app_generator_test.rb -n test_config_another_database
Run options: -n test_config_another_database --seed 7260
# Running:
F
Failure:
AppGeneratorTest#test_config_another_database [test/generators/app_generator_test.rb:417]:
Expected /^\s*gem\s+["']mysql2["'], '~> 0.4.4'$*/ to match "source 'https://rubygems.org'\ngit_source(:github) { |repo| \"https://github.com/\#{repo}.git\" }\n\nruby '2.5.0'\n\n# Bundle edge Rails instead: gem 'rails', github: 'rails/rails'\ngem 'rails', '~> 6.0.0.alpha'\n# Use mysql as the database for Active Record\ngem 'mysql2', '>= 0.4.4', '< 0.6.0'\n# Use Puma as the app server\ngem 'puma', '~> 3.11'\n# Use SCSS for stylesheets\ngem 'sass-rails', '~> 5.0'\n# Use Uglifier as compressor for JavaScript assets\ngem 'uglifier', '>= 1.3.0'\n# See https://github.com/rails/execjs#readme for more supported runtimes\n# gem 'mini_racer', platforms: :ruby\n\n# Use CoffeeScript for .coffee assets and views\ngem 'coffee-rails', '~> 4.2'\n# Turbolinks makes navigating your web application faster. Read more: https://github.com/turbolinks/turbolinks\ngem 'turbolinks', '~> 5'\n# Build JSON APIs with ease. Read more: https://github.com/rails/jbuilder\ngem 'jbuilder', '~> 2.5'\n# Use Redis adapter to run Action Cable in production\n# gem 'redis', '~> 4.0'\n# Use ActiveModel has_secure_password\n# gem 'bcrypt', '~> 3.1.7'\n\n# Use ActiveStorage variant\n# gem 'mini_magick', '~> 4.8'\n\n# Use Capistrano for deployment\n# gem 'capistrano-rails', group: :development\n\n# Reduces boot times through caching; required in config/boot.rb\ngem 'bootsnap', '>= 1.1.0', require: false\n\ngroup :development, :test do\n # Call 'byebug' anywhere in the code to stop execution and get a debugger console\n gem 'byebug', platforms: [:mri, :mingw, :x64_mingw]\nend\n\ngroup :development do\n # Access an interactive console on exception pages or by calling 'console' anywhere in the code.\n gem 'web-console', '>= 3.3.0'\n gem 'listen', '>= 3.0.5', '< 3.2'\n # Spring speeds up development by keeping your application running in the background. Read more: https://github.com/rails/spring\n gem 'spring'\n gem 'spring-watcher-listen', '~> 2.0.0'\nend\n\ngroup :test do\n # Adds support for Capybara system testing and selenium driver\n gem 'capybara', '>= 2.15', '< 4.0'\n gem 'selenium-webdriver'\n # Easy installation and use of chromedriver to run system tests with Chrome\n gem 'chromedriver-helper'\nend\n\n# Windows does not include zoneinfo files, so bundle the tzinfo-data gem\ngem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]\n".
bin/rails test test/generators/app_generator_test.rb:411
Finished in 0.174681s, 5.7247 runs/s, 34.3483 assertions/s.
1 runs, 6 assertions, 1 failures, 0 errors, 0 skips
```
Adds the ability to dump the schema or structure files for mulitple
databases. Loops through the configs for a given env and sets a filename
based on the format, then establishes a connection for that config and
dumps into the file.
`each_current_configuration` is used by create, drop, and other methods
to find the configs for a given environment and returning those to the
method calling them.
The change here allows for the database commands to operate on all the
configs in the environment. Previously we couldn't slice the hashes and
iterate over them becasue they could be two tier or could be three
tier. By using the database config structs we don't need to care whether
we're dealing with a three tier or two tier, we can just parse all the
configs based on the environment.
This makes it possible for us to run `bin/rails db:create` and it will
create all the configs for the dev and test environment ust like it does
for a two tier - it creates the db for dev and test. Now `db:create`
will create `primary` for dev and test, and `animals` for dev and test
if our database.yml looks like:
```
development:
primary:
etc
animals:
etc
test:
primary:
etc
animals:
etc
```
This means that `bin/rails db:create`, `bin/rails db:drop`, and
`bin/rails db:migrate` will operate on the dev and test env for both
primary and animals ds.
If we have a three-tier yaml file like this:
```
development:
primary:
database: "development"
animals:
database: "development_animals"
migrations_paths: "db/animals_migrate"
```
This will add db create/drop/and migrate tasks for each level of the
config under that environment.
```
bin/rails db:drop:primary
bin/rails db:drop:animals
bin/rails db:create:primary
bin/rails db:create:animals
bin/rails db:migrate:primary
bin/rails db:migrate:animals
```
Passing around and parsing hashes is easy if you know that it's a two
tier config and each key will be named after the environment and each
value will be the config for that environment key.
This falls apart pretty quickly with three-tier configs. We have no idea
what the second tier will be named (we know the first is primary but we
don't know the second), we have no easy way of figuring out
how deep a hash we have without iterating over it, and we'd have to do
this a lot throughout the code since it breaks all of Active Record's
assumptions regarding configurations.
These methods allow us to pass around objects instead. This will allow
us to more easily parse the configs for the rake tasks. Evenually I'd
like to replace the Active Record connection management that passes
around config hashes to use these methods as well but that's much
farther down the road.
`walk_configs` takes an environment, specification name, and a config
and turns them into DatabaseConfig struct objects so we can ask the
configs questions like:
```
db_config.spec_name
=> animals
db_config.env_name
=> development
db_config.config
{ :adapter => mysql etc }
```
`db_configs` loops through all given configurations and returns an array
of DatabaseConfig structs for each config in the yaml file.
and lastly `configs_for` takes an environment and either returns the
spec name and config if a block is given or returns an array of
DatabaseConfig structs just for the given environment.
This gets called many times for each virtual_path, creating a new string
each time that `translate` is called. We can memoize this so that it
only happens once per virtual_path instead.
"my string #{nil}" results in an additional '' string allocation, I'm
guessing because the nil has to be converted to a string.
"my string #{'[]' if multiple}" results in "my string #{nil}" if
multiple is false. Doing "my string #{''}" does not result in an extra
string allocation. I moved the if multiple logic into a method so I only
had to make the change once.
```ruby
begin
require "bundler/inline"
rescue LoadError => e
$stderr.puts "Bundler version 1.10 or later is required. Please update
your Bundler"
raise e
end
gemfile(true) do
source "https://rubygems.org"
gem "benchmark-ips"
gem "rails"
end
def allocate_count
GC.disable
before = ObjectSpace.count_objects
yield
after = ObjectSpace.count_objects
after.each { |k,v| after[k] = v - before[k] }
after[:T_HASH] -= 1 # probe effect - we created the before hash.
GC.enable
result = after.reject { |k,v| v == 0 }
GC.start
result
end
@html_options = {}
def master_version(multiple=nil)
"hi#{"[]" if multiple}"
end
def fast_version(multiple=nil)
str = multiple ? "[]" : ''
"hi#{str}"
end
def test
puts "master_version"
puts allocate_count { 1000.times { master_version } }
puts "master_version with arg"
puts allocate_count { 1000.times { master_version(' there') } }
puts "fast_version"
puts allocate_count { 1000.times { fast_version } }
puts "fast_version with arg"
puts allocate_count { 1000.times { fast_version(' there') } }
Benchmark.ips do |x|
x.report("master_version") { master_version }
x.report("master_version with arg") { master_version(' there') }
x.report("fast_version") { fast_version }
x.report("fast_version with arg") { fast_version(' there') }
x.compare!
end
end
test
```
results:
```ruby
master_version
{:FREE=>-1981, :T_STRING=>2052}
master_version with arg
{:FREE=>-1001, :T_STRING=>1000}
fast_version
{:FREE=>-1001, :T_STRING=>1000}
fast_version with arg
{:FREE=>-1001, :T_STRING=>1000}
Warming up --------------------------------------
master_version 138.851k i/100ms
master_version with arg
164.029k i/100ms
fast_version 165.737k i/100ms
fast_version with arg
167.016k i/100ms
Calculating -------------------------------------
master_version 2.464M (±14.7%) i/s - 11.941M in 5.023307s
master_version with arg
3.754M (± 8.5%) i/s - 18.699M in 5.021354s
fast_version 3.449M (±11.7%) i/s - 17.071M in 5.033312s
fast_version with arg
3.636M (± 6.9%) i/s - 18.205M in 5.034792s
Comparison:
master_version with arg: 3753896.1 i/s
fast_version with arg: 3636094.5 i/s - same-ish: difference falls within error
fast_version: 3448766.2 i/s - same-ish: difference falls within error
master_version: 2463857.3 i/s - 1.52x slower
```
Reasons are that the Qu gem wasn't compatible since Rails 5.1,
gem development was stopped in 2014 and maintainers have
confirmed its demise. See issue #32273