| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
| |
One of the author fixture we have ("david") references an author address by ID.
Since we disable FK checks when inserting fixtures, this is all fine until we
try to update it, at which point MySQL would complain about the missing row
referenced by the `author_address_id`.
[Godfrey Chan, Matthew Draper]
|
| | |
|
| |
|
|
|
|
| |
`reload` is meant to put a record in the same state it would be if you
were to do `Post.find(post.id)`. This means we should fully replace the
attributes hash.
|
| |\
| |
| | |
Introduce an Attribute object to handle the type casting dance
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There's a lot more that can be moved to these, but this felt like a good
place to introduce the object. Plans are:
- Remove all knowledge of type casting from the columns, beyond a
reference to the cast_type
- Move type_cast_for_database to these objects
- Potentially make them mutable, introduce a state machine, and have
dirty checking handled here as well
- Move `attribute`, `decorate_attribute`, and anything else that
modifies types to mess with this object, not the columns hash
- Introduce a collection object to manage these, reduce allocations, and
not require serializing the types
|
| |/
|
|
|
|
| |
Topics call `serialize :content`, which means that the values in the
database should be YAML encoded, and we would only expect to receive
YAML strings to `update_column` and `update_columns`.
|
| |\
| |
| | |
Bring type casting behavior of hstore/json in line with serialized
|
| | |
| |
| |
| |
| | |
`@raw_attributes` should not contain the type-cast, mutable version of
the value.
|
| |\ \
| |/
|/|
| | |
Baseclass becomes! subclass
|
| | | |
|
| |/
|
|
|
| |
Closes #15122
Closes #15107
|
| |
|
|
|
| |
This case prevents against regressions. The change was suggested in a recent
PR but the all our tests passed.
|
| |
|
|
|
| |
Also change other related test to use existing record rather than
creating new one.
|
| | |
|
| |
|
|
|
| |
Avoid rounding problems with `.usec` method rounding the seconds when the
field doesn't persist the `.usec` piece.
|
| | |
|
| |
|
| |
Without this, the original record's values won't get saved, since the partial insertions support (https://github.com/rails/rails/commit/144e8691cbfb8bba77f18cfe68d5e7fd48887f5e) checks for changed values and thinks there are none.
|
| | |
|
| |
|
|
|
| |
The method got extracted out from AR::Base in commit
d916c62cfc7c59ab6411407a05b946d3dd7535e9, but the tests never did.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It was added because a regression caused by a712e08ebe21f6d8653a0e6602df2e0f5d40d9ca
Closes #9255
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When applying default_scope to a class with a where clause, using
update_column(s) could generate a query that would not properly update
the record due to the where clause from the default_scope being applied
to the update query.
class User < ActiveRecord::Base
default_scope where(active: true)
end
user = User.first
user.active = false
user.save!
user.update_column(:active, true) # => false
In this situation we want to skip the default_scope clause and just
update the record based on the primary key. With this change:
user.update_column(:active, true) # => true
Fixes #8436.
|
| | |
|
| |
|
|
| |
If you want to change the STI type too, use AR::Base.becomes! instead
|
| |
|
|
| |
Didn't work before because it updated the model-in-memory first, so the DB query couldn't find the record.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit a7f4b0a1231bf3c65db2ad4066da78c3da5ffb01.
Conflicts:
activerecord/lib/active_record/associations/has_one_association.rb
activerecord/lib/active_record/persistence.rb
activerecord/test/cases/base_test.rb
activerecord/test/cases/dirty_test.rb
activerecord/test/cases/timestamp_test.rb
|
| |
|
|
|
|
| |
update_column was suggested as replacement of update_attribute at the
last release of 3-2-stable, so deprecating it now will confuse the
users.
|
| |
|
|
|
|
|
| |
It doesn't serve much purpose now that ActiveRecord::Base.all returns a
Relation.
The code is moved to active_record_deprecated_finders.
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously it returned an Array.
If you want an array, call e.g. `Post.to_a` rather than `Post.all`. This
is more explicit.
In most cases this should not break existing code, since
Relations use method_missing to delegate unknown methods to #to_a
anyway.
|
| |
|
|
| |
Closes #1190
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Historically, update_attribute and update_attributes are similar, but
with one big difference: update_attribute does not run validations.
These two methods are really easy to confuse given their similar
names. Therefore, update_attribute is being removed in favor of
update_column.
See the thread on rails-core here:
https://groups.google.com/forum/?fromgroups#!topic/rubyonrails-core/BWPUTK7WvYA
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
things
|
| | |
|
| | |
|
| |
|
|
| |
Closes #5202 and #919
|
