- 23 9月, 2012 2 次提交
-
-
由 Francesco Rodriguez 提交于
-
由 Francesco Rodriguez 提交于
-
- 19 9月, 2012 1 次提交
-
-
由 Guillermo Iguaran 提交于
-
- 17 9月, 2012 1 次提交
-
-
由 Guillermo Iguaran 提交于
-
- 15 9月, 2012 1 次提交
-
-
由 Jon Leighton 提交于
This reverts commit c24c8852. 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
-
- 08 9月, 2012 2 次提交
-
-
由 Carlos Antonio da Silva 提交于
* There is no need to delete the primary key from cloned attributes, since it sets the same pk to nil afterwards. * Check for empty? instead of any? to run initialize callbacks.
-
由 Aaron Patterson 提交于
transaction.
-
- 21 8月, 2012 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 18 8月, 2012 2 次提交
-
-
由 Jon Leighton 提交于
any? will check that each item in the array is truthy, as opposed to !empty? which will simply check that the array has length. For an empty array, !empty? still seems to be faster than any?
-
由 Jon Leighton 提交于
deep_dup is slow. we only need to dup the values, so just do that directly.
-
- 11 8月, 2012 1 次提交
-
-
由 Jon Leighton 提交于
It's not really a good idea to have this as a global config option. We should allow people to specify the behaviour per association. There will now be two new values: * :dependent => :restrict_with_exception implements the current behaviour of :restrict. :restrict itself is deprecated in favour of :restrict_with_exception. * :dependent => :restrict_with_error implements the new behaviour - it adds an error to the owner if there are dependent records present See #4727 for the original discussion of this.
-
- 03 8月, 2012 2 次提交
-
-
由 Xavier Noria 提交于
-
由 Xavier Noria 提交于
-
- 28 7月, 2012 1 次提交
-
-
由 Rafael Mendonça França 提交于
This reverts commit 14fc8b34. Reason: we need to discuss a better path from this removal. Conflicts: activerecord/lib/active_record/reflection.rb activerecord/test/cases/base_test.rb activerecord/test/models/developer.rb
-
- 16 7月, 2012 1 次提交
-
-
由 Kang Wen 提交于
-
- 19 6月, 2012 1 次提交
-
-
由 Steve Klabnik 提交于
This feature adds a lot of complication to ActiveRecord for dubious value. Let's talk about what it does currently: class Customer < ActiveRecord::Base composed_of :balance, :class_name => "Money", :mapping => %w(balance amount) end Instead, you can do something like this: def balance @balance ||= Money.new(value, currency) end def balance=(balance) self[:value] = balance.value self[:currency] = balance.currency @balance = balance end Since that's fairly easy code to write, and doesn't need anything extra from the framework, if you use composed_of today, you'll have to add accessors/mutators like that. Closes #1436 Closes #2084 Closes #3807
-
- 16 6月, 2012 1 次提交
-
-
由 Jon Leighton 提交于
Get rid of ActiveModel::Configuration, make better use of ActiveSupport::Concern + class_attribute, etc.
-
- 10 6月, 2012 1 次提交
-
-
由 Andrew White 提交于
There are two possible scenarios where the @mass_assignment_options instance variable can become corrupted: 1. If the assign_attributes doesn't complete correctly, then subsequent calls to a nested attribute assignment method will use whatever options were passed to the previous assign_attributes call. 2. With nested assign_attributes calls, the inner call will overwrite the current options. This will only affect nested attributes as the attribute hash is sanitized before any methods are called. To fix this we save the current options in a local variable and then restore these options in an ensure block.
-
- 30 5月, 2012 1 次提交
-
-
由 kennyj 提交于
-
- 27 5月, 2012 1 次提交
-
-
由 Francesco Rodriguez 提交于
-
- 18 5月, 2012 1 次提交
-
-
由 Peter Suschlik 提交于
-
- 17 5月, 2012 1 次提交
-
-
由 Mark Rushakoff 提交于
-
- 15 5月, 2012 3 次提交
-
-
由 Peter Suschlik 提交于
-
由 Carlos Antonio da Silva 提交于
Introduced in 7ecfe3d3
-
由 Oscar Del Ben 提交于
-
- 12 5月, 2012 4 次提交
-
-
由 Vijay Dev 提交于
-
由 Vijay Dev 提交于
-
由 Vijay Dev 提交于
-
由 Erich Menge 提交于
Add #nodoc to initialize_dup and use :method: to document the #dup method. Relates to issue #6235
-
- 07 5月, 2012 1 次提交
-
-
由 Piotr Sarnacki 提交于
-
- 05 5月, 2012 1 次提交
-
-
由 Piotr Sarnacki 提交于
-
- 03 4月, 2012 1 次提交
-
-
由 Benedikt Deicke 提交于
The #relation method gets called in four places and the return value was instantly cloned in three of them. The only place that did not clone was ActiveRecord::Scoping::Default::ClassMethods#unscoped. This introduced a bug described in #5667 and should really clone the relation, too. This means all four places would clone the relation, so it doesn't make a lot of sense caching it in the first place. The four places with calls to relations are: activerecord/lib/active_record/scoping/default.rb:110:in `block in build_default_scope'" activerecord/lib/active_record/scoping/default.rb:42:in `unscoped'" activerecord/lib/active_record/scoping/named.rb:38:in `scoped'" activerecord/lib/active_record/scoping/named.rb:52:in `scope_attributes'"
-
- 30 3月, 2012 1 次提交
-
-
由 Guillermo Iguaran 提交于
-
- 15 3月, 2012 1 次提交
-
-
由 Bogdan Gusiev 提交于
-
- 14 3月, 2012 1 次提交
-
-
由 kennyj 提交于
-
- 04 3月, 2012 1 次提交
-
-
由 Carlos Antonio da Silva 提交于
This apparently fix the warning related to @new_record variable not being initialized in AR's test suit, when an association is built and the object is marshalled/loaded. See these tests in AR's base_test.rb: test_marshalling_with_associations test_marshalling_new_record_round_trip_with_associations Closes #3720.
-
- 14 2月, 2012 1 次提交
-
-
由 Akira Matsuda 提交于
-
- 08 2月, 2012 3 次提交
-
-
由 Jon Leighton 提交于
-
由 Aaron Patterson 提交于
-
由 Aaron Patterson 提交于
-