| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
This reverts commit edc54fd2068bc21f0d381228e55d97e32f508923, reversing
changes made to a5922f132f4d163e2c7f770427087f5268c18def.
As discussed, this is not an appropriate place to make assumptions about
ARGV, or to write to stdout: config/boot.rb is a library and is required
by other applictions, with which we have no right to interfere.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rails has some support for multiple databases but it can be hard to
handle migrations with those. The easiest way to implement multiple
databases is to contain migrations into their own folder ("db/migrate"
for the primary db and "db/seconddb_migrate" for the second db). Without
this you would need to write code that allowed you to switch connections
in migrations. I can tell you from experience that is not a fun way to
implement multiple databases.
This refactoring is a pre-requisite for implementing other features
related to parallel testing and improved handling for multiple
databases.
The refactoring here moves the class methods from the `Migrator` class
into it's own new class `MigrationContext`. The goal was to move the
`migrations_paths` method off of the `Migrator` class and onto the
connection. This allows users to do the following in their
`database.yml`:
```
development:
adapter: mysql2
username: root
password:
development_seconddb:
adapter: mysql2
username: root
password:
migrations_paths: "db/second_db_migrate"
```
Migrations for the `seconddb` can now be store in the
`db/second_db_migrate` directory. Migrations for the primary database
are stored in `db/migrate`".
The refactoring here drastically reduces the internal API for migrations
since we don't need to pass `migrations_paths` around to every single
method. Additionally this change does not require any Rails applications
to make changes unless they want to use the new public API. All of the
class methods from the `Migrator` class were `nodoc`'d except for the
`migrations_paths` and `migrations_path` getter/setters respectively.
|
| |
|
| |
|
|\
| |
| | |
Fix comment about initializers to adapt to the fact
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently the comment says application configuration should go into
files in `config/initializers`.
However some configuration couldn't initialize correctly because of the
initializing process(e.g. `config.time_zone`).
It should be changed by framework but this is large change and it may occur
malfunction to some applications which depends on current initializing
process.
So this comment is changed to adapt to the fact.
|
|\ \
| | |
| | | |
Use SHA-1 for non-sensitive digests by default
|
| | |
| | |
| | |
| | |
| | |
| | | |
Instead of providing a configuration option to set the hash function,
switch to SHA-1 for new apps and allow upgrading apps to opt in later
via `new_framework_defaults_5_2.rb`.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
alternative
Closes #31273 but we will still want to upgrade this to the
nonce-approach when it’s ready.
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | | |
PostgreSQL: Allow pg-1.0 gem to be used with ActiveRecord
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
pg-1.0.0 is just released and most Gemfiles don't restrict
it's version. But the version is checked when connecting to
the database, which leads to the following error:
Gem::LoadError: can't activate pg (~> 0.18), already activated pg-1.0.0
See also this pg issue:
https://bitbucket.org/ged/ruby-pg/issues/270/pg-100-x64-mingw32-rails-server-not-start
Preparation for pg-1.0 was done in commit f28a331023fab,
but the pg version constraint was not yet relaxed.
|
|\ \ \ \
| |/ / /
|/| | | |
Add support for Minitest 5.11
|
| | | |
| | | |
| | | |
| | | | |
Ref: http://docs.seattlerb.org/minitest/Minitest/Result.html#attribute-i-klass
|
| | | |
| | | |
| | | |
| | | |
| | | | |
`filtered_results` returns an instance of `Minitest::Result` since https://github.com/seattlerb/minitest/commit/00433fc0a4fdd0e6b302aace633384ba13122376
`Minitest::Result` is not test class. So cannot get location directly.
|
|\ \ \ \
| |_|/ /
|/| | | |
Don't include Active Storage migrations in new apps
|
| | | |
| | | |
| | | |
| | | | |
See #31315 for full discussion
|
| |/ /
|/| |
| | |
| | | |
start the Rails server
|
| |/
|/|
| |
| |
| |
| |
| | |
Before Rails 4.0, `config.cache_classes` determined whether application
code was eager loaded. The `config.eager_load` option was introduced to
allow the two behaviours to be configured independently, but this
documentation was never updated to reflect that change.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `app:update` rake task will regenerate `development.rb` so that it
contains this option; that means we're currently adding it to existing
apps in two places, which is unnecessary and confusing.
Also:
- Remove inaccurate comment about which stack frames are ignored
- Clarify that the feature uses `caller_locations`, not `caller`
- Remove unused return value in `extract_callstack`
|
| |
| |
| |
| |
| |
| |
| | |
Specifying the `--dev` option is when want to change the codebase,
as it is not necessary to cache it.
Context: https://github.com/rails/rails/pull/31485#issuecomment-352452653
|
|\ \
| | |
| | | |
Raise an error only when `require_master_key` is specified
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
To prevent errors from being raise in environments where credentials
is unnecessary.
Context: https://github.com/rails/rails/issues/31283#issuecomment-348801489
Fixes #31283
|
| |
| |
| | |
Be consistent in comments when mentioning AES.
|
|/
|
|
|
|
| |
`bootsnap` is a useful gem normally. However, `bootsnap` is unnecessary
when generating a Rails application to be used only for testing.
So I want to control whether use this or not by option.
|
|\
| |
| | |
Provide instant feedback when booting Rails
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I've noticed during pair/mob programming sessions with peers that
despite the speed boosts provided by Bootsnap and Spring, there is a
noticeable latency between firing a bin/rails server command and any
feedback being provided to the console. Depending on the size of the
application this lack of feedback can make it seem like something is
wrong when Rails is simply busy initializing.
This change may seem gratuitous but by just printing one line to STDOUT
we're giving a clear signal to the Rails user that their command has
been received and that Rails is indeed booting. It almost imperciptibly
makes Rails feel more responsive.
Sure the code doesn't look very fancy but there's no other appropriate
place I could think of putting it than boot.rb.
Compare these two GIFs of booting without and with this change:
Before:
![Without Boot Feedback](https://user-images.githubusercontent.com/65950/33964140-721041fc-e025-11e7-9b25-9d839ce92977.gif)
After:
![With Boot Feedback](https://user-images.githubusercontent.com/65950/33964151-79e12f86-e025-11e7-93e9-7a75c70d408f.gif)
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new ActiveRecord configuration option allows you to easily
pinpoint what line of application code is triggering SQL queries in the
development log by appending below each SQL statement log the line of
Ruby code that triggered it.
It’s useful with N+1 issues, and to locate stray queries.
By default this new option ignores Rails and Ruby code in order to
surface only callers from your application Ruby code or your gems.
It is enabled on newly generated Rails 5.2 applications and can be
enabled on existing Rails applications:
```ruby
Rails.application.configure do
# ...
config.active_record.verbose_query_logs = true
end
```
The `rails app:upgrade` task will also add it to
`config/development.rb`.
This feature purposely avoids coupling with
ActiveSupport::BacktraceCleaner since ActiveRecord can be used without
ActiveRecord. This decision can be reverted in the future to allow more
configurable backtraces (the exclusion of gem callers for example).
|
| |
|
|
|
|
|
|
|
| |
a94220b66c9e4890007f66b092b25f8a64a19d31:
- The namespacing should be `ActiveRecord::FixtureSet`
- I might be missing something but I'm not sure why `create_fixtures` is useful for nowaday (unless for testing rails internal /shrug) and since it's been that long it wasn't working I think it should be fine to just fire it
|
|
|
|
|
|
|
|
|
| |
Option parsing happens too late to have any impact on the Rails
environment. Rails accesses the environment name and memoizes it too
early in the boot process for a commandline option to have any impact on
the database connection, so we'll change this test to set the
environment from an environment variable (and ensure it still works when
running tests with `ruby`)
|
|
|
|
| |
This reverts commit 9a80f52541ed2c93ebef02909ecab3aaf9127150.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I frequently run tests with `ruby`, not with a runner like `rake` or
`rails`. When running the test with just `ruby` the `RAILS_ENV`
environment variable did not get set to "test", and this would cause the
tests to fail (and even mutate the development database!)
This commit adds integration tests for running tests with just `ruby`
and ensures the environment gets defaulted to "test". I also added a
test to ensure that passing an environment to `-e` actually works (and
fixed that case too).
An interesting / annoying thing is that Minitest picks up it's plugins
by asking RubyGems for a list of files:
https://github.com/seattlerb/minitest/blob/ca6a71ca901016db09a5ad466b4adea4b52a504a/lib/minitest.rb#L92-L100
This means that RubyGems needs to somehow know about the file before it
can return it to Minitest. Since we are not packaging Rails as a Gem
before running the integration tests on it (duh, why would you do
that?), RubyGems doesn't know about the file, so it can't tell Minitest,
so Minitest doesn't automatically require it. This means I had to
manually require and insert the plugin in our integration test. I've
left comments about that in the test as well.
Ugh.
|
|\
| |
| | |
Drop the before_fork/on_worker_boot advice
|
| |
| |
| |
| |
| | |
It's no longer required for Active Record, and other common libraries
(dalli, redis-rb) all seem to be fork-proof too.
|
| | |
|
| |
| |
| |
| | |
Fixes #31286
|
| |
| |
| |
| | |
Fixes #31282.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `keyfile` was renamed to `credentials` in `google-cloud-storage` 1.8.0.
https://github.com/GoogleCloudPlatform/google-cloud-ruby/blob/master/google-cloud-storage/CHANGELOG.md#180--2017-11-14
Although `keyfile` can still be used, but it looks like deprecate.
https://github.com/GoogleCloudPlatform/google-cloud-ruby/blob/ddf7b2a856d676316525eb581c1a4cc83ca6097b/google-cloud-storage/lib/google/cloud/storage.rb#L589...L590
Therefore, I think that should use `credentials` in newly generated
applications.
Ref: https://github.com/GoogleCloudPlatform/google-cloud-ruby/issues/1802
|
| | |
|
| |
| |
| |
| | |
Follow up of 924a368f5c654f5304e575c767eb0fc64adc8659
|
| | |
|
| |
| |
| |
| |
| | |
This will keep the behavior of an application with the defaults of a 4.2
or 5.0 application behaving the same when upgrading to 5.2.
|
|/
|
|
|
|
| |
Since `ContentSecurityPolicy::Middleware` is not loaded in API-only
Applications, initializer is unnecessary.
Ref: https://github.com/rails/rails/blob/9c10fec4c06da38f8975dfb851f4d899aa85f8b7/railties/lib/rails/application/default_middleware_stack.rb#L66..L68
|
|
|
|
| |
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
|
|
|
|
|
|
|
| |
In order to use early hints, need to use Puma 3.11.0 or higher.
So, I think that should specify that version in newly generated applications.
Ref: https://github.com/puma/puma/commit/f6f3892f4d82638fb7a2a57d993641b1486ee88a
|
|\
| |
| | |
Clean database naming ambiguity
|
| |
| |
| |
| | |
In some places this file referred to the database in three different ways: database, DB and db. The last one caused confusion with the db namespace and the db folder. This commit removes this ambiguity by using the whole word 'database' everywhere
|