Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Feb 25, 2013
  1. @yaotti
Commits on Feb 20, 2013
  1. @wangjohn

    Reduced memory leak problem in transactions by lazily updating AR obj…

    wangjohn authored
    …ects with new transaction state. If AR object has a callback, the callback will be performed immediately (non-lazily) so the transaction still has to keep records with callbacks.
Commits on Jan 22, 2013
  1. @rafaelfranca

    Whitespaces :scissors:

    rafaelfranca authored
    [ci skip]
Commits on Jan 20, 2013
  1. @wangjohn
  2. @wangjohn
Commits on Nov 21, 2012
  1. @jonleighton

    Don't allocate new strings in compiled attribute methods

    jonleighton authored
    This improves memory and performance without having to use symbols which
    present DoS problems. Thanks @headius and @tenderlove for the
    This was originally committed in
    f176501, and then reverted in
    d349490 due to it causing problems in a
    real application. This second attempt should solve that.
    require 'active_record'
    require 'benchmark/ips'
    ActiveRecord::Base.establish_connection(adapter: 'sqlite3', database: ':memory:')
    class Post < ActiveRecord::Base
      connection.create_table :posts, force: true do |t|
        t.string :name
    post = Post.create name: 'omg'
    Benchmark.ips do |r|'')          { name: 'omg' }'')         { }'')        { = 'omg' }'Post.find(1).name') { Post.find(1).name }
    Calculating -------------------------------------
            1419 i/100ms
           7538 i/100ms
          3024 i/100ms
       Post.find(1).name       243 i/100ms
          20637.6 (±12.7%) i/s -     102168 in   5.039578s
       1167897.7 (±18.2%) i/s -    5186144 in   4.983077s
        64305.6 (±9.6%) i/s -     317520 in   4.998720s
       Post.find(1).name     2678.8 (±10.8%) i/s -      13365 in   5.051265s
    Calculating -------------------------------------
            1431 i/100ms
           7790 i/100ms
          3181 i/100ms
       Post.find(1).name       245 i/100ms
          21308.8 (±12.2%) i/s -     105894 in   5.053879s
       1534103.8 (±2.1%) i/s -    7634200 in   4.979405s
        67441.0 (±7.5%) i/s -     337186 in   5.037871s
       Post.find(1).name     2681.9 (±10.6%) i/s -      13475 in   5.084511s
Commits on Nov 16, 2012
  1. @vijaydev

    Merge branch 'master' of

    vijaydev authored
Commits on Nov 9, 2012
  1. @carlosantoniodasilva

    Remove not used load hooks for active_record_config

    carlosantoniodasilva authored
    These were removed with ActiveRecord::Model in
Commits on Nov 8, 2012
  1. @AvnerCohen

    1.9 hash syntax changes

    AvnerCohen authored
Commits on Oct 26, 2012
  1. @jonleighton
  2. @jonleighton

    Remove ActiveRecord::Model

    jonleighton authored
    In the end I think the pain of implementing this seamlessly was not
    worth the gain provided.
    The intention was that it would allow plain ruby objects that might not
    live in your main application to be subclassed and have persistence
    mixed in. But I've decided that the benefit of doing that is not worth
    the amount of complexity that the implementation introduced.
Commits on Oct 20, 2012
  1. @jeremy
Commits on Oct 19, 2012
  1. @jonleighton

    Get rid of the ActiveRecord::Model::DeprecationProxy thing.

    jonleighton authored
    I think it's going to be too much pain to try to transition the
    :active_record load hook from executing against Base to executing
    against Model.
    For example, after Model is included in Base, and modules included in
    Model will no longer get added to the ancestors of Base.
    So plugins which wish to be compatible with both Model and Base should
    use the :active_record_model load hook which executes *before* Base gets
    In general, ActiveRecord::Model is an advanced feature at the moment and
    probably most people will continue to inherit from ActiveRecord::Base
    for the time being.
Commits on Sep 19, 2012
  1. @guilleiguaran
Commits on Sep 17, 2012
  1. @guilleiguaran
Commits on Sep 14, 2012
  1. @jonleighton

    Revert "create a transaction object and point AR objects at that obje…

    jonleighton authored
    …ct during a"
    This reverts commit c24c885.
    Here's the explanation I just sent to @tenderlove:
    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 }
    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:
    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
    In my testing, this finalizers make GC quite expensive:
    Ruby 2.0 will have a native WeakRef implementation (via
    ObjectSpace::WeakMap), hence won't be reliant on finalizers:
    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:
    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!
Commits on Sep 7, 2012
  1. @carlosantoniodasilva

    Minor refactor in ActiveRecord#initialize_dup

    carlosantoniodasilva authored
    * 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.
  2. @tenderlove
Commits on Aug 20, 2012
  1. @tenderlove
Commits on Aug 17, 2012
  1. @jonleighton

    Avoid #any?

    jonleighton authored
    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?
  2. @jonleighton

    Avoid deep_dup when intantiating.

    jonleighton authored
    deep_dup is slow. we only need to dup the values, so just do that
Commits on Aug 10, 2012
  1. @jonleighton

    Remove the dependent_restrict_raises option.

    jonleighton authored
    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
    * :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.
Commits on Aug 2, 2012
  1. @fxn
  2. @fxn
Commits on Jul 27, 2012
  1. @rafaelfranca

    Revert "Removing composed_of from ActiveRecord."

    rafaelfranca authored
    This reverts commit 14fc8b3.
    Reason: we need to discuss a better path from this removal.
Commits on Jul 16, 2012
  1. @wkang
Commits on Jun 18, 2012
  1. @steveklabnik

    Removing composed_of from ActiveRecord.

    steveklabnik authored
    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)
    Instead, you can do something like this:
        def balance
          @balance ||=, currency)
        def balance=(balance)
          self[:value] = balance.value
          self[:currency] = balance.currency
          @balance = balance
    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
Commits on Jun 15, 2012
  1. @jonleighton

    Simplify AR configuration code.

    jonleighton authored
    Get rid of ActiveModel::Configuration, make better use of
    ActiveSupport::Concern + class_attribute, etc.
Commits on Jun 10, 2012
  1. @pixeltrix

    Ensure that mass assignment options are preserved

    pixeltrix authored
    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.
Commits on May 30, 2012
  1. @kennyj
Commits on May 27, 2012
  1. @frodsan
Commits on May 18, 2012
  1. @splattael

    Fix typo.

    splattael authored
Commits on May 17, 2012
  1. @vijaydev

    Merge branch 'master' of

    vijaydev authored
Commits on May 16, 2012
  1. @mark-rushakoff
Commits on May 15, 2012
  1. @splattael

    Fix typo [ci skip]

    splattael authored
Something went wrong with that request. Please try again.