| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This only existed to support methods like `set_table_name` in Active
Record, which are themselves being deprecated.
|
| | |
|
| |
| |
| |
| | |
method.
|
| | |
|
|/
|
|
| |
destoyed without catching the ActiveRecord::StaleObjectError.
|
| |
|
|
|
|
| |
RUNNING_UNIT_TESTS file for details, but essentially you can now configure things in test/config.yml. You can also run tests directly via the command line, e.g. ruby path/to/test.rb (no rake needed, uses default db connection from test/config.yml). This will help us fix the CI by enabling us to isolate the different Rails versions to different databases.
|
|
|
|
| |
delete method.
|
|
|
|
| |
Signed-off-by: Santiago Pastorino and José Ignacio Costa <santiago+jose@wyeworks.com>
|
| |
|
| |
|
|
|
|
| |
fixtures when the DB does not support savepoints. This speeds the test run up by about 8-9% on my computer, when running rake test_sqlite3_mem :)
|
| |
|
| |
|
| |
|
|
|
| |
This makes a test fail, but it is revealing a bug in Arel master.
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now works with :dependent => :destroy and includes unit tests for that
case. Also includes better error messages when updating/deleting stale
objects.
[#1966 state:committed]
Signed-off-by: Jeremy Kemper <jeremy@bitsweat.net>
|