| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Using heredoc would enforce line wrapping to whatever column width we decided to
use in the code, making it difficult for the users to read on some consoles.
This does make the source code read slightly worse and a bit more error-prone,
but this seems like a fair price to pay since the primary purpose for these
messages are for the users to read and the code will not stick around for too
long.
|
| |
|
|
| |
[ci skip]
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, Active Record will rescue any errors raised within
after_rollback/after_create callbacks and print them to the
logs. Next versions of rails will not rescue those errors anymore,
and just bubble them up, as the other callbacks.
This adds a opt-in flag to enable that behaviour, of not rescuing
the errors.
Example:
# For not swallow errors in after_commit/after_rollback
config.active_record.errors_in_transactional_callbacks = true
[fixes #13460]
|
| |\
| |
| |
| |
| |
| |
| | |
Remove dead branch when restoring ID within a transaction
Conflicts:
activerecord/lib/active_record/transactions.rb
|
| | |
| |
| |
| |
| |
| |
| | |
There is no way to have an instance of an Active Record model where
`has_attribute?(self.class.primary_key)` returns false. The record is
always initialized in such a way that `@raw_attributes` will have an id
key with nil for the value.
|
| |/
|
|
|
|
|
| |
Reduces the number of places that care about the internals of how we
store and type cast attributes. We do not need to go through the
dup/freeze dance, as you couldn't have saved a frozen new record anyway,
and that is the only time we would end up modifying the frozen hash.
|
| |
|
|
|
|
|
|
|
| |
`@attributes` was actually used for `_before_type_cast` and friends,
while `@attributes_cache` is the type cast version (and caching is the
wrong word there, but I'm working on removing the conditionals around
that). I opted for `@raw_attributes`, because `_before_type_cast` is
also semantically misleading. The values in said hash are in the state
given by the form builder or database, so raw seemed to be a good word.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We are using that code path in only one place so we should not add a
conditional to all the other cases. This will avoid performance
regressions on the old paths.
|
| | |
|
| |
|
|
|
|
| |
Make sure when we clean the `@_start_transaction_state` var we do it in
the same code-path.
Also this makes `clear_transaction_record_state`, more consistent with `restore_transaction_record_state`
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rollback"
We are reverting these commits, because there are other caveats related
to dirty attributes not being restored when a transaction is rollback.
For instance, nested transactions cannot proper restore the dirty
attributes state after a rollback.
At the moment, the dirty attributes are scoped by the transaction.
When we call `.save` on a record, the dirty attributes will be reset even
if the transaction gets rollback.
[related #13166]
[related #15018]
[related #15016]
[closes #15019]
This reverts commits
* bab48f0a3d53a08bc23ea0887219e8deb963c3d9
* b0fa7cf3ff8432cc2eef3682b34763b7f8c93cc8.
* 73fb39b6faa9de593ae75ad4e3b8e065ea0e53af
* 37c238927fbed059de3f26a90d8923fb377568a5.
* 8d8d4f1560264cd1c74364d67fa0501f6dd2c4fa
Revert "Merge pull request #13166 from bogdan/transaction-magic"
|
| | |
|
| |
|
|
| |
[related #13166]
|
| |\
| |
| |
| | |
[Regression 3.2 -> 4.0] Fix bugs with changed attributes tracking when transaction gets rollback
|
| | | |
|
| | |
| |
| |
| | |
custom primary_key that didn't save due to validation error
|
| | |
| |
| |
| | |
[fixes #12566]
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This has been added 9 years ago in
a677da209b16f43198b3485dda89dce862fb9bfb, and removed 6 years ago in
38f8252e2d0a109d1b833d6b289cd989e7bfffe4.
|
| |/
|
|
| |
callbacks
|
| |
|
| |
Fixed syntax error on `after_commit` docs
|
| |
|
|
|
|
|
|
|
|
|
|
| |
`rollback_active_record_state!` tries to restore model state on `Exception`
by invoking `restore_transaction_record_state` it decrement deep level by `1`.
After restoring it ensure that states to be cleared
and level decremented by invoking `clear_transaction_record_state`,
which cause the bug: because state already reduced in `restore_transaction_record_state`.
Removed double derement of transaction level
and removed duplicated code which clear transaction state for top level.
|
| |
|
|
|
|
|
|
|
| |
Right before that in `assert_valid_transaction_action` method we make
sure that `options[:on]` contains values from `ACTIONS` array
(`[:create, :destroy, :update]`) and nothing more (i.e. it could not
contain strings or something else, otherwise the error is raised).
Also I've polished some docs.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 9bf1a0db4acbbf9e8e6f707250269185224e7efe, reversing
changes made to fed97091b9546d369a240d10b184793d49247dd3.
Conflicts:
activerecord/test/cases/transaction_callbacks_test.rb
Reason: This fix introduces another issue described at #8937, so we are
reverting it to restore the behavior of 3-2-stable.
We will fix both issues when we come out with a better solution
|
| |
|
|
|
| |
http://www.sqlite.org/lang_savepoint.html
https://github.com/rails/rails/blob/master/activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb#L130-L132
|
| |
|
|
| |
Closes #988.
|
| |
|
|
| |
fixes #5802
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
during a"
This reverts commit c24c885209ac2334dc6f798c394a821ee270bec6.
Here's the explanation I just sent to @tenderlove:
Hey,
I've been thinking about about the transaction memory leak thing that we
were discussing.
Example code:
post = nil
Post.transaction do
N.times { post = Post.create }
end
Post.transaction is going to create a real transaction and there will
also be a (savepoint) transaction inside each Post.create.
In an idea world, we'd like all but the last Post instance to be GC'd,
and for the last Post instance to receive its after_commit callback when
Post.transaction returns.
I can't see how this can work using your solution where the Post itself
holds a reference to the transaction it is in; when Post.transaction
returns, control does not switch to any of Post's instance methods, so
it can't trigger the callbacks itself.
What we really want is for the transaction itself to hold weak
references to the objects within the transaction. So those objects can
be GC'd, but if they are not GC'd then the transaction can iterate them
and execute their callbacks.
I've looked into WeakRef implementations that are available. On 1.9.3,
the stdlib weakref library is broken and we shouldn't use it.
There is a better implementation here:
https://github.com/bdurand/ref/blob/master/lib/ref/weak_reference/pure_ruby.rb
We could use that, either by pulling in the gem or just copying the code
in, but it still suffers from the limitation that it uses ObjectSpace
finalizers.
In my testing, this finalizers make GC quite expensive:
https://gist.github.com/3722432
Ruby 2.0 will have a native WeakRef implementation (via
ObjectSpace::WeakMap), hence won't be reliant on finalizers:
http://bugs.ruby-lang.org/issues/4168
So the ultimate solution will be for everyone to use Ruby 2.0, and for
us to just use ObjectSpace::WeakMap.
In the meantime, we have basically 3 options:
The first is to leave it as it is.
The second is to use a finalizer-based weakref implementation and take
the GC perf hit.
The final option is to store object ids rather than the actual objects.
Then use ObjectSpace._id2ref to deference the objects at the end of the
transaction, if they exist. This won't stop memory use growing within
the transaction, but it'll grow more slowly.
I benchmarked the performance of _id2ref this if the object does or does
not exist: https://gist.github.com/3722550
If it does exist it seems decent, but it's hugely more expensive if it
doesn't, probably because we have to do the rescue nil.
Probably most of the time the objects will exist. However the point of
doing this optimisation is to allow people to create a large number of
objects inside a transaction and have them be GC'd. So for that use
case, we'd be replacing one problem with another. I'm not sure which of
the two problems is worse.
My feeling is that we should just leave this for now and come back to it
when Ruby 2.0 is out.
I'm going to revert your commit because I can't see how it solves this.
Hope you don't mind... if I've misunderstood then let me know!
Jon
|
| |
|
|
| |
transaction.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This fixes issue #3217.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, when saving a frozen record, an exception would be thrown
which causes a rollback. However, there is a bug in active record that
"defrost" the record as a side effect:
>> t = Topic.new
=> #<Topic id: nil, ...>
>> t.freeze
=> #<Topic id: nil, ...>
>> t.save
RuntimeError: can't modify a frozen Hash
>> t.frozen?
=> false
>> t.save
=> true
This patch fixes the bug by explictly restoring the frozen state on the
attributes Hash after every rollback.
|
| |\
| |
| | |
Allow manual rollbacks in after_save to reset object correctly
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
