| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| |
| |
| |
| | |
Application* stubs
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \ |
|
| | | |
|
| |\ \
| | | |
| | | | |
Introduce ApplicationRecord, an Active Record layer supertype
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It's pretty common for folks to monkey patch `ActiveRecord::Base` to
work around an issue or introduce extra functionality. Instead of
shoving even more stuff in `ActiveRecord::Base`, `ApplicationRecord` can
hold all those custom work the apps may need.
Now, we don't wanna encourage all of the application models to inherit
from `ActiveRecord::Base`, but we can encourage all the models that do,
to inherit from `ApplicationRecord`.
Newly generated applications have `app/models/application_record.rb`
present by default. The model generators are smart enough to recognize
that newly generated models have to inherit from `ApplicationRecord`,
but only if it's present.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Running railties generated app tests in development env can cause unintended
consequences. The environments are different and tests aren't meant to be
run in development mode.
The changes to the generator exposed this issue where the random test
order in the generated apps could cause problems when those tests are
run in development mode.
Particularly we saw failures in `railties/test/application/rake_test.rb`
generated apps that used the scaffold to create applications and then
run the migration and immediately run the tests. The error we saw was
`ActiveRecord::RecordNotFound: Couldn't find User with 'id'=980190962`
and seemed to only occur if the destroy test ran first. I'm not entirely
sure _why_ this causes that error to be thrown but I believe it is
related to the environments being different.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In Rails 5.1 `ActionController::TestCase` will be moved out of Rails
into it's own gem. Please use `ActionDispatch::IntegrationTest` going
forward.
This changes the generators to use `ActionDispatch::IntegrationTest` and
the required URL setup (rather than symbols) for each of the controller
actions.
Updated fix to #22076.
|
| |/ /
| | |
| | |
| | | |
We will wait until 5.1 to make a decision
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
to change that in config/environments/production.rb
|
| | | |
|
| | |
| | |
| | |
| | | |
Indeed we need this to be an engine for the internal assets to work
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
That would make possible to use it with action cable configuration.
|
|\| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Apart from specific versioning support, our tests should focus on the
behaviour of whatever version they're accompanying, regardless of when
they were written.
Application code should *not* do this.
|
| | | |
|
| | |
| | |
| | |
| | | |
Rahm Emanuel doesn't deserve to be in Rails.
|
| | |
| | |
| | |
| | | |
Otherwise assets will not work
|
| | | |
|
| | | |
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 9712a7a12b7f9e4dcef751ceda8a73c3f4beb11f, reversing
changes made to 3e65c3d3886336e9145438cdeacaf4ebec6a48b8.
Reverting because this caused test failures and while we have a followup
branch there is still one failure that happens randomly and isn't
straight forward to fix.
|
|\ \
| | |
| | | |
Controller generators should be creating IntegrationTest stubs instea…
|
| | |
| | |
| | |
| | | |
ControllerTest
|
|\ \ \ |
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
Allows any Rake task to be run through `bin/rails` such as `bin/rails db:migrate`,
`bin/rails notes` etc.
The Rake tasks are appended to Rails' help output, and blend in as standard commands.
|
|\ \ \
| | | |
| | | | |
Prevent a 500 in the default controller scaffold
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If you update a record with no attributes, you'll hit a 500 from a guard
in `assign_attributes` raising:
```ruby
ArgumentError: When assigning attributes, you must pass a hash as an argument.
app/controllers/users_controller.rb:44:in `block in update'
app/controllers/users_controller.rb:43:in `update'
test/controllers/users_controller_test.rb:37:in `block in <class:UsersControllerTest>'
```
Not a biggie, but may be quite confusing for the folks new to the
framework.
|
|\ \ \
| | | |
| | | | |
Update web-console to 3.0.0
|
| |/ /
| | |
| | |
| | |
| | | |
Web Console 3.0.0 is compatible with Rails 5, while the 2.x.x releases
aren't.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The API isn't ready yet, which means we haven't documented it.
People can't make their own commands, so there's no reason to show it
in generated documentation.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this commit, the sole presence of the Listen constant
enabled the evented file watcher (unless listen resorted to
the polling backend).
This way, applications may depend on listen for other stuff
independently of this feature. Also, allows teams with mixed
setups to decide at boot time whether the evented watcher
should be enabled for each particular instance.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since the absolute path is not required to re-run the test,
modified so that unnecessary information is not displayed.
```ruby
# before
bin/rails test /path/to/blorgh/test/integration/navigation_test.rb:5
# after
bin/rails test test/integration/navigation_test.rb:5
```
|
| | |
|
| | |
|
| |
| |
| |
| | |
is the default value for only API apps
|
| | |
|
| | |
|
| | |
|