| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
The previous commit changes the state of the class, and while we are
cleaning up the database, I forgot to clean up the class
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've added a redundant test for this under the attributes API as well,
as that also causes this bug to manifest through public API (and
demonstrates that calling `reset_column_information` on the child
classes would be insufficient)
Since children of a class should always share a table with their parent,
just reloading the schema from the cache should be sufficient here.
`reload_schema_from_cache` should probably become public and
`# :nodoc:`, but I'd rather avoid the git churn here.
Fixes #22057
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`widgets` table is being created in `primary_keys_test.rb` for PostgreSQLAdapter, MysqlAdapter, Mysql2Adapter
and it makes test to fail earlier.
Before:
`bundle exec rake mysql2:test`
```
Finished in 127.287669s, 35.5258 runs/s, 97.8885 assertions/s.
1) Error:
PersistenceTest::SaveTest#test_save_touch_false:
ActiveModel::UnknownAttributeError: unknown attribute 'name' for #<Class:0x0000000a7d6ef0>.
/home/kd/projects/kd-rails/activerecord/lib/active_record/attribute_assignment.rb:36:in `rescue in _assign_attribute'
/home/kd/projects/kd-rails/activerecord/lib/active_record/attribute_assignment.rb:34:in `_assign_attribute'
/home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:40:in `block in _assign_attributes'
/home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:39:in `each'
/home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:39:in `_assign_attributes'
/home/kd/projects/kd-rails/activerecord/lib/active_record/attribute_assignment.rb:26:in `_assign_attributes'
/home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:33:in `assign_attributes'
/home/kd/projects/kd-rails/activerecord/lib/active_record/core.rb:293:in `initialize'
/home/kd/projects/kd-rails/activerecord/lib/active_record/inheritance.rb:61:in `new'
/home/kd/projects/kd-rails/activerecord/lib/active_record/inheritance.rb:61:in `new'
/home/kd/projects/kd-rails/activerecord/lib/active_record/persistence.rb:50:in `create!'
/home/kd/projects/kd-rails/activerecord/test/cases/persistence_test.rb:913:in `test_save_touch_false'
4522 runs, 12460 assertions, 0 failures, 1 errors, 4 skips
```
After:
`bundle exec rake mysql2:test`
```
Finished in 135.785086s, 33.3026 runs/s, 91.7774 assertions/s.
4522 runs, 12462 assertions, 0 failures, 0 errors, 4 skips
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I’m renaming all instances of `use_transcational_fixtures` to
`use_transactional_tests` and “transactional fixtures” to
“transactional tests”.
I’m deprecating `use_transactional_fixtures=`. So anyone who is
explicitly setting this will get a warning telling them to use
`use_transactional_tests=` instead.
I’m maintaining backwards compatibility—both forms will work.
`use_transactional_tests` will check to see if
`use_transactional_fixtures` is set and use that, otherwise it will use
itself. But because `use_transactional_tests` is a class attribute
(created with `class_attribute`) this requires a little bit of hoop
jumping. The writer method that `class_attribute` generates defines a
new reader method that return the value being set. Which means we can’t
set the default of `true` using `use_transactional_tests=` as was done
previously because that won’t take into account anyone using
`use_transactional_fixtures`. Instead I defined the reader method
manually and it checks `use_transactional_fixtures`. If it was set then
it should be used, otherwise it should return the default, which is
`true`. If someone uses `use_transactional_tests=` then it will
overwrite the backwards-compatible method with whatever they set.
|
| | |
|
| |
|
|
|
| |
- This is based on https://github.com/rails/rails/issues/18400 but
tackling same issue with update_attribute method instead of update method.
|
| |\
| |
| |
| |
| |
| |
| | |
Changed ActiveRecord::Relation#update behavior so that it will work on Relation objects without giving id
Conflicts:
activerecord/CHANGELOG.md
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
callbacks and validations
- Right now, there is no method to update multiple records with
validations and callbacks.
- Changed the behavior of existing `update` method so that when `id`
attribute is not given and the method is called on an `Relation`
object, it will execute update for every record of the `Relation` and
will run validations and callbacks for every record.
- Added test case for validating that the callbacks run when `update` is
called on a `Relation`.
- Changed test_create_columns_not_equal_attributes test from
persistence_test to include author_name column on topics table as it
it used in before_update callback.
- This change introduces performance issues when a large number of
records are to be updated because it runs UPDATE query for every
record of the result. The `update_all` method can be used in that case
if callbacks are not required because it will only run single UPDATE
for all the records.
|
| |/
|
|
| |
timestamps. [#18202]
|
| | |
|
| |
|
|
|
| |
`Computer` class needs to be require
See #17217 for more details
|
| |
|
|
|
|
|
|
|
| |
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
|
