- 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
-
- 13 9月, 2012 7 次提交
-
-
由 Matt Jones 提交于
-
由 Thiago Pradi 提交于
-
由 Jon Leighton 提交于
In some circumstances engine was Arel::Table.engine which for separate reasons was an ActiveRecord::Model::DeprecationProxy, which caused a deprecation warning. In any case, we want the actual model class here, since we want to use it to infer information about associations.
-
由 Jon Leighton 提交于
-
由 Jon Leighton 提交于
Previously the reflection would be looked up on the wrong class. However the test passed because the examples referred back to themselves.
-
由 Marc-Andre Lafortune 提交于
-
由 Robert Evans 提交于
single-table inheritance by overriding it in your ActiveRecord Model.
-
- 12 9月, 2012 5 次提交
-
-
由 Arun Agrawal 提交于
1. Unused variable 2. possibly useless use of a variable in void context
-
由 Grace Liu 提交于
- added tests to confirm establish_connection uses DATABASE_URL and Rails.env correctly even when no arguments are passed in. - updated rake db tasks to support DATABASE_URL, and added tests to confirm correct behavior for these rake tasks. (Removed establish_connection call from some tasks since in those cases the :environment task already made sure the function would be called) - updated Resolver so that when it resolves the database url, it removes hash values with empty strings from the config spec (e.g. to support connection to postgresql when no username is specified).
-
由 beerlington 提交于
Allows you to specify the model association key in a belongs_to relationship instead of the foreign key. The following queries are now equivalent: Post.where(:author_id => Author.first) Post.where(:author => Author.first) PriceEstimate.where(:estimate_of_type => 'Treasure', :estimate_of_id => treasure) PriceEstimate.where(:estimate_of => treasure)
-
由 kennyj 提交于
-
由 kennyj 提交于
-
- 11 9月, 2012 1 次提交
-
-
由 Jonathan Rochkind 提交于
As a result of different commits, ConnectionPool had become of two minds about exceptions, sometimes using PoolFullError and sometimes using ConnectionTimeoutError. In fact, it was using ConnectionTimeoutError internally, but then recueing and re-raising as a PoolFullError. There's no reason for this bifurcation, standardize on ConnectionTimeoutError, which is the rails2 name and still accurately describes semantics at this point. History In Rails2, ConnectionPool raises a ConnectionTimeoutError if it can't get a connection within timeout. Originally in master/rails3, @tenderlove had planned on removing wait/blocking in connectionpool entirely, at that point he changed exception to PoolFullError. But then later wait/blocking came back, but exception remained PoolFullError. Then in 02b23355 pmahoney introduced fair waiting logic, and brought back ConnectionTimeoutError, introducing the weird bifurcation. ConnectionTimeoutError accurately describes semantics as of this point, and is backwards compat with rails2, there's no reason for PoolFullError to be introduced, and no reason for two different exception types to be used internally, no reason to rescue one and re-raise as another. Unify!
-
- 10 9月, 2012 3 次提交
-
-
由 kennyj 提交于
-
由 kennyj 提交于
-
由 Sebastian Korfmann 提交于
Exception message was misleading, as it is possible to have a polymorphic 'has_many :through' join model.
-
- 09 9月, 2012 5 次提交
-
-
由 Vijay Dev 提交于
-
由 Arun Agrawal 提交于
-
由 Ernie Miller 提交于
When calling a query method on an attribute that was not selected by an ActiveRecord query, an ActiveModel::MissingAttributeError is not raised. Instead, a nil value is returned, which will return false once cast to boolean. This is undesirable, as we should not give the impression that we know the attribute's boolean value when we haven't loaded the attribute's (possibly) non-boolean value from the database. This issue is present on versions going back as far as 2.3, at least.
-
由 Francesco Rodriguez 提交于
-
由 Francesco Rodriguez 提交于
-
- 08 9月, 2012 7 次提交
-
-
由 Carlos Antonio da Silva 提交于
-
由 Carlos Antonio da Silva 提交于
-
由 Konstantin Shabanov 提交于
-
由 Carlos Antonio da Silva 提交于
Merged in f41dba27 [ci skip]
-
由 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.
-
由 Carlos Antonio da Silva 提交于
Check 0180e090 for more reasoning about that.
-
- 07 9月, 2012 5 次提交
-
-
由 Carlos Antonio da Silva 提交于
Since 810a50da, the new policy is to keep old changelogs in their own branches, to avoid manual syncing across different branches. Please check that commit for more reasoning about the new policy.
-
由 Carlos Antonio da Silva 提交于
-
由 Prem Sichanugrist 提交于
-
由 Jan Bernacki 提交于
move validation to AR
-
由 Yves Senn 提交于
-
- 06 9月, 2012 6 次提交
-
-
由 Rafael Mendonça França 提交于
This will solve the issue that abort the connection transaction when we skip the tests.
-
由 Dickson S. Guedes 提交于
This implements the support to encode/decode JSON data to/from database and creating columns of type JSON using a native type [1] supported by PostgreSQL from version 9.2. [1] http://www.postgresql.org/docs/9.2/static/datatype-json.html
-
由 Rafael Mendonça França 提交于
-
由 Ian Lesperance 提交于
-
由 Andreas Loupasakis 提交于
-
由 Seamus Abshere 提交于
The previous implementation had the strange requirement that db/structure.sql contain only CREATE TABLE sql statements, one per table, separated by double newlines. SQLite3 and PostgreSQL database tasks, on the other hand, simply spawn 'sqlite3' and 'psql' binaries to load the file directly. The new implementation follows this and attempts to respect all current MySQL configuration settings.
-