| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| | |
|
| |
|
|
|
|
| |
`ActiveRecord::Persistence#touch` does not work well when optimistic
locking enabled and `locking_column`, without default value, is null in
the database.
|
| |
|
|
|
|
|
| |
Fix destroying existing object does not work well when optimistic
locking enabled and `locking column` is null in the database.
Follow 22a822e5813ef7ea9ab6dbbb670a363899a083af, #28914
|
| |
|
|
|
|
|
|
|
| |
Add test to ensure that locking_column cannot be updated explicitly.
Add test to prevent regression on creating new object with
explicit value locking_column.
Related to #28318
|
| | |
|
| | |
|
| |
|
|
| |
Actually, private methods cannot be called with `self.`, so it's not just redundant, it's a bad habit in Ruby
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this the changes to the lock version column will stick around
even after `touch` returns.
Before:
model.touch
model.changes
# => {"lock_version"=>[0, "1"]}
After:
model.touch
model.changes
# {}
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
|
|
|
|
|
|
| |
Make sure we handle explicitly passed nil's to lock_version as well.
An explicitly passed nil value is now converted to 0 on LockingType,
so that we don't end up with ActiveRecord::StaleObjectError in update record
optimistic locking
Fixes #24695
|
| |
|
|
|
|
| |
Some tests does not work for unprepared statements.
Add `if ActiveRecord::Base.connection.prepared_statements` and fix a
regex for fix tests failure with `prepared_statements: false`.
|
| |
|
|
|
| |
There was a test remaining for PG only that was checking for an exact
limit clause
|
| |
|
|
|
|
|
|
| |
Since the counter cache was properly being updated, the model became
stale. Simply reloading the model before attempting to destroy is
sufficient for this case. I believe this is enough of an edge case to be
a valid change to the tests, even though it represents a potential
breaking change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also removes a false positive test that depends on the fixed bug:
At this time, counter_cache does not work with polymorphic relationships
(which is a bug). The test was added to make sure that no
StaleObjectError is raised when the car is destroyed. No such error is
currently raised because the lock version is not incremented by
appending a wheel to the car.
Furthermore, `assert_difference` succeeds because `car.wheels.count`
does not check the counter cache, but the collection size. The test will
fail if it is replaced with `car.wheels_count || 0`.
|
| |
|
|
|
|
|
|
|
|
| |
Fixes #19776
change test variable names and use more verbose on method
less verbose
use _read_attribute instead of send
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reason this bug occured is that we never actually check to see if
this column has changed from it's default, since it was never assigned
and is not mutable.
It appears I was wrong in b301c40224c6d15b539dbcc7485adb44d810f88c, with
my statement of "there is no longer a case where a given value would
differ from the default, but would not already be marked as changed."
However, I chose not to revert the deletion of
`initialize_internals_callback` from that commit, as I think a solution
closer to where the problem lies is less likely to get erroneously
removed. I'm not super happy with this solution, but it mirrors what is
being done in `_update_record`, and a fix for one should work for the
other.
I toyed with the idea of changing the definition of `changed?` on the
type to `changed_in_place?`. If we type cast the raw value, it'll break
a test about updating not modifying the lock column if nothing else was
changed. We could have the definition check if `raw_old_value` is `nil`,
but this feels fragile and less intention revealing. It would, however,
have the benefit of cleaning up old data that incorrectly persisted as
`nil`.
Fixes #18422
|
| | |
|
| |
|
|
|
| |
This fixes <"SQLite3::SQLException: no such column: legacy_things.person_id: SELECT \"legacy_things\".* FROM \"legacy_things\" WHERE \"legacy_things\".\"person_id\" = ?">
in OptimisticLockingTest#test_lock_destroy
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
- fixes #13788
As per the documentation at lock!, if the :lock option is a string it should use the given SQL to generate the lock statement.
|
| | |
|
| |
|
|
|
|
| |
This includes fixing typos in changelog, removing a deprecated
mocha/setup test require, and preferring the `column_for_attribute`
accessor over direct access to the columns_hash in the new code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When calling quote_value the underlying connection sometimes requires
more information about the column to properly return the correct quoted
value.
I ran into this issue when using optimistic locking in JRuby and the
activerecord-jdbcmssql-adapter. In SQLSever 2000, we aren't allowed to
insert a integer into a NVARCHAR column type so we need to format it as
N'3' if we want to insert into the NVARCHAR type. Unfortuantely, without
the column type being passed the connection adapter cannot properly return
the correct quote value because it doesn't know to return N'3' or '3'.
This patch is fairly straight forward where it just passes in the column
type into the quote_value, as it already has the ability to take in the column,
so it can properly handle at the connection level.
I've added the tests required to make sure that the quote_value method
is being passed the column type so that the underlying connection can
determine how to quote the value.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Method `delete_all` should not be invoking callbacks and this
feature was deprecated in Rails 4.0. This is being removed.
`delete_all` will continue to honor the `:dependent` option. However
if `:dependent` value is `:destroy` then the default deletion
strategy for that collection will be applied.
User can also force a deletion strategy by passing parameter to
`delete_all`. For example you can do `@post.comments.delete_all(:nullify)`
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
When partial inserts are enabled, overridden db defaults are ignored. This
results in locking columns having a nil value for new records if the db default
is null. This happens because the list of changed attributes for new records is
always assumed to be empty.
Solution: When a new record's default attributes are set, also initialize the
list of changed attributes by comparing current values against what's stored as
the column defaults in the database.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a `with_lock` method to ActiveRecord objects, which starts
a transaction, locks the object (pessimistically) and yields to the block.
The method takes one (optional) parameter and passes it to `lock!`.
Before:
class Order < ActiveRecord::Base
def cancel!
transaction do
lock!
# ... cancelling logic
end
end
end
After:
class Order < ActiveRecord::Base
def cancel!
with_lock do
# ... cancelling logic
end
end
end
|
