| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The new association error belongs to Active Record, not Active Model.
See #18700 for reference.
|
|\| | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
activerecord/CHANGELOG.md
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Post.where('id = 1').or(Post.where('id = 2'))
# => SELECT * FROM posts WHERE (id = 1) OR (id = 2)
[Matthew Draper & Gael Muller]
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
These callbacks will already have been defined when the association was
built. The check against `reflection.autosave` happens at call time, not
at define time, so simply modifying the reflection is sufficient.
Fixes #18704
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Given that this was originally added to normalize an error that would
have otherwise come from the database (inconsistently), it's more
natural for us to raise in `type_cast_for_database`, rather than
`type_cast_from_user`. This way, things like numericality validators can
handle it instead if the user chooses to do so. It also fixes an issue
where assigning an out of range value would make it impossible to assign
a new value later.
This fixes several vague issues, none of which were ever directly
reported, so I have no issue number to give. Places it was mentioned
which I can remember:
- https://github.com/thoughtbot/shoulda-matchers/blob/9ba21381d7caf045053a81f32df7de2f49687820/lib/shoulda/matchers/active_model/allow_value_matcher.rb#L261-L263
- https://github.com/rails/rails/issues/18653#issuecomment-71197026
|
| | | | |
| | | | |
| | | | |
| | | | | |
Fixes #18580.
|
| | |/ /
| |/| |
| | | |
| | | | |
Fixes #18632
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Keeping with our behavior elsewhere in the system, invalid input is
assumed to be `nil`.
Fixes #18629.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This method can be used to see all of the fields on a model which have
been read. This can be useful during development mode to quickly find
out which fields need to be selected. For performance critical pages, if
you are not using all of the fields of a database, an easy performance
win is only selecting the fields which you need. By calling this method
at the end of a controller action, it's easy to determine which fields
need to be selected.
While writing this, I also noticed a place for an easy performance win
internally which I had been wanting to introduce. You cannot mutate a
field which you have not read. Therefore, we can skip the calculation of
in place changes if we have never read from the field. This can
significantly speed up methods like `#changed?` if any of the fields
have an expensive mutable type (like `serialize`)
```
Calculating -------------------------------------
#changed? with serialized column (before)
391.000 i/100ms
#changed? with serialized column (after)
1.514k i/100ms
-------------------------------------------------
#changed? with serialized column (before)
4.243k (± 3.7%) i/s - 21.505k
#changed? with serialized column (after)
16.789k (± 3.2%) i/s - 84.784k
```
|
| |\ \ \
| | | | |
| | | | | |
Support after_commit callbacks in transactional fixtures
|
| | | |/
| | |/|
| | | |
| | | |
| | | |
| | | | |
after_commit callbacks run after committing a transaction whose parent
is not `joinable?`: un-nested transactions, transactions within test
cases, and transactions in `console --sandbox`.
|
| |\ \ \
| | | | |
| | | | | |
Add an `:if_exists` option to `drop_table`
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
If set to `if_exists: true`, it generates a statement like:
DROP TABLE IF EXISTS posts
This syntax is supported in the popular SQL servers, that is (at least)
SQLite, PostgreSQL, MySQL, Oracle and MS SQL Sever.
Closes #16366.
|
| |/ / / |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
- This is based on https://github.com/rails/rails/issues/18400 but
tackling same issue with update_attribute method instead of update method.
|
| |/ / |
|
| | |
| | |
| | |
| | |
| | |
| | | |
The types that are affected by `time_zone_aware_attributes` (which is on
by default) have been made configurable, in case this is a breaking
change for existing applications.
|
| | |
| | |
| | |
| | |
| | |
| | | |
There's very little value in logging "<NULL binary data>" instead of
just "nil". I'd like to remove the column from the equation entirely,
and this case is preventing us from doing so.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This sets a precident for how we handle `attribute` calls, which aren't
backed by a database column. We should not take this as a conscious
decision on how to handle them, and this can change when we make
`attribute` public if we have better ideas in the future.
As the composed attributes API gets fleshed out, I expect the
`persistable_attributes` method to change to
`@attributes.select(&:persistable).keys`, or some more performant
variant there-of. This can probably go away completely once we fully
move dirty checking into the attribute objects once it gets moved up to
Active Model.
Fixes #18407
|
| | | |
|
| |/
| |
| |
| | |
Related to #10690.
|
| | |
|
| |\
| | |
| | |
| | |
| | |
| | | |
prathamesh-sonpatki/add-test-for-non-string-labeled-fixtures
Fix lookup of fixtures with non-string(like Fixnum) label
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Fixtures with non-string labels such as integers should be accessed
using integer label as key. For eg. pirates(1) or pirates(42).
- But this results in NotFound error because the label is converted into string before
looking up into the fixtures hash.
- After this commit, the label is converted into string only if its a
symbol.
- This issue was fount out while adding a test case for
https://github.com/rails/rails/commit/7b910917.
|
| | |
|
| |
| |
| |
| | |
Addresses https://github.com/rails/rails/commit/ed56e596a0467390011bc9d56d462539776adac1#commitcomment-9145960
|
| |
| |
| |
| | |
addresses https://github.com/rails/rails/commit/91949e48cf41af9f3e4ffba3e5eecf9b0a08bfc3#commitcomment-9144563
|
| |
| |
| |
| | |
This adresses https://github.com/rails/rails/commit/1b7aa62b184c4410c99208f71b59bbac5c5f03be#commitcomment-9147803
|
| | |
|
| |
| |
| |
| |
| |
| | |
Update SecureToken Docs
Add Changelog entry for has_secure_token [ci skip]
|
| |
| |
| |
| |
| |
| |
| |
| | |
Before this change we had a small set of "truthy", and all others
are "falsy".
Now, we have a small set of "falsy" values and all others are
"truthy" matching Ruby's semantics.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Before this change any error raised inside a transaction callback
are rescued and printed in the logs.
Now these errors are not rescue anymore and just bubble up,
as the other callbacks.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Now all strings will be handled as a URL.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit ae96f229f6501d8635811d6b22d75d43cdb880a4.
Conflicts:
activerecord/CHANGELOG.md
activerecord/lib/active_record/attribute_methods.rb
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This stems from [a comment](rails#17227 (comment)) by @dhh.
In summary:
* New Rails 5.0 apps will not accept `return false` as a way to halt callback chains, and will not display a deprecation warning.
* Existing apps ported to Rails 5.0 will still accept `return false` as a way to halt callback chains, albeit with a deprecation warning.
For this purpose, this commit introduces a Rails configuration option:
```ruby
config.active_support.halt_callback_chains_on_return_false
```
For new Rails 5.0 apps, this option will be set to `false` by a new initializer
`config/initializers/callback_terminator.rb`:
```ruby
Rails.application.config.active_support.halt_callback_chains_on_return_false = false
```
For existing apps ported to Rails 5.0, the initializers above will not exist.
Even running `rake rails:update` will not create this initializer.
Since the default value of `halt_callback_chains_on_return_false` is set to
`true`, these apps will still accept `return true` as a way to halt callback
chains, displaying a deprecation warning.
Developers will be able to switch to the new behavior (and stop the warning)
by manually adding the line above to their `config/application.rb`.
A gist with the suggested release notes to add to Rails 5.0 after this
commit is available at https://gist.github.com/claudiob/614c59409fb7d11f2931
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this commit, returning `false` in an ActiveRecord `before_` callback
such as `before_create` would halt the callback chain.
After this commit, the behavior is deprecated: will still work until
the next release of Rails but will also display a deprecation warning.
The preferred way to halt a callback chain is to explicitly `throw(:abort)`.
|
|/ |
|
|\
| |
| |
| | |
Clear query cache on rollback
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add setting of FK for throgh associations while building
Conflicts:
activerecord/CHANGELOG.md
activerecord/test/cases/associations/has_many_through_associations_test.rb
|
| | | |
|