1. 20 1月, 2014 13 次提交
  2. 19 1月, 2014 8 次提交
    • R
      Merge pull request #13762 from robertomiranda/spring-under-rails · 935d235f
      Robin Dupret 提交于
      Update Changelog, Spring is under rails/spring [ci skip]
      935d235f
    • R
      7671590f
    • R
      Merge pull request #13759 from raysrashmi/rails-spring · 0c96f8ab
      Robin Dupret 提交于
      Spring in now under rails/spring [ci skip]
      0c96f8ab
    • R
      Spring in now under rails/spring [ci skip] · b20d4453
      Rashmi Yadav 提交于
      b20d4453
    • A
      Merge pull request #13756 from huoxito/rails-spring · ab91bc31
      Andrew White 提交于
      spring gem moved to rails/spring
      ab91bc31
    • W
      spring gem moved to rails/spring · e05c7912
      Washington Luiz 提交于
      e05c7912
    • G
      Merge pull request #13751 from chancancode/ar_rollback_fix · 3c354bd8
      Godfrey Chan 提交于
      Restore ActiveRecord states after a rollback for models w/o callbacks
      3c354bd8
    • G
      Restore ActiveRecord states after a rollback for models w/o callbacks · 7386ffc7
      Godfrey Chan 提交于
      This fixes a regression (#13744) that was caused by 67d8bb96.
      
      In 67d8bb96, we introduced lazy rollback for records, such that the
      record's internal states and attributes are not restored immediately
      after a transaction rollback, but deferred until they are first
      accessed.
      
      This optimization is only performed when the model does not have any
      transactional callbacks (e.g. `after_commit` and `after_create`).
      
      Unfortunately, the models used to test the affected codepaths all
      comes with some sort of transactional callbacks. Therefore this
      codepath remains largely untested until now and as a result there are
      a few issues in the implementation that remains hidden until now.
      
      First, the `sync_with_transaction_state` (or more accurately,
      `update_attributes_from_transaction_state`) would perform the
      synchronization prematurely before a transaction is finalized (i.e.
      comitted or rolled back). As a result, when the actuall rollback
      happens, the record will incorrectly assumes that its internal states
      match the transaction state, and neglect to perform the restore.
      
      Second, `update_attributes_from_transaction_state` calls `committed!`
      in some cases. This in turns checks for the `destroyed?` state which
      also requires synchronization with the transaction stae, which causes
      an infnite recurrsion.
      
      This fix works by deferring the synchronization until the transaction
      has been finalized (addressing the first point), and also unrolled
      the `committed!` and `rolledback!` logic in-place (addressing the
      second point).
      
      It should be noted that the primary purpose of the `committed!` and
      `rolledback!` methods are to trigger the relevant transactional
      callbacks. Since this code path is only entered when there are no
      transactional callbacks on the model, this shouldn't be necessary. By
      unrolling the method calls, the intention here (to restore the states
      when necessary) becomes more clear.
      7386ffc7
  3. 18 1月, 2014 7 次提交
  4. 17 1月, 2014 12 次提交