1. 31 5月, 2014 1 次提交
    • S
      Rename attribute related instance variables to better express intent · eb6cee9c
      Sean Griffin 提交于
      `@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.
      eb6cee9c
  2. 23 5月, 2014 1 次提交
    • G
      Fixed serialization for records with an attribute named `format`. · 2d73f5ae
      Godfrey Chan 提交于
      * * *
      
      This bug can be triggered when serializing record R (the instance) of type C
      (the class), provided that the following conditions are met:
      
      1. The name of one or more columns/attributes on C/R matches an existing private
         method on C (e.g. those defined by `Kernel`, such as `format`).
      
      2. The attribute methods have not yet been generated on C.
      
      In this case, the matching private methods will be called by the serialization
      code (with no arguments) and their return values will be serialized instead. If
      the method requires one or more arguments, it will result in an `ArgumentError`.
      
      This regression is introduced in d1316bb1.
      
      * * *
      
      Attribute methods (e.g. `#name` and `#format`, assuming the class has columns
      named `name` and `format` in its database table) are lazily defined. Instead of
      defining them when a the class is defined (e.g. in the `inherited` hook on
      `ActiveRecord::Base`), this operation is deferred until they are first accessed.
      
      The reason behind this is that is defining those methods requires knowing what
      columns are defined on the database table, which usually requires a round-trip
      to the database. Deferring their definition until the last-possible moment helps
      reducing unnessary work, especially in development mode where classes are
      redefined and throw away between requests.
      
      Typically, when an attribute is first accessed (e.g. `a_book.format`), it will
      fire the `method_missing` hook on the class, which triggers the definition of
      the attribute methods. This even works for methods like `format`, because
      calling a private method with an explicit receiver will also trigger that hook.
      
      Unfortunately, `read_attribute_for_serialization` is simply an alias to `send`,
      which does not respect method visibility. As a result, when serializing a record
      with those conflicting attributes, the `method_missing` is not fired, and as a
      result the attribute methods are not defined one would expected.
      
      Before d1316bb1, this is negated by the fact that calling the `run_callbacks`
      method will also trigger a call to `respond_to?`, which is another trigger point
      for the class to define its attribute methods. Therefore, when Active Record
      tries to run the `after_find` callbacks, it will also define all the attribute
      methods thus masking the problem.
      
      * * *
      
      The proper fix for this problem is probably to restrict `read_attribute_for_serialization`
      to call public methods only (i.e. alias `read_attribute_for_serialization` to
      `public_send` instead of `send`). This however would be quite risky to change
      in a patch release and would probably require a full deprecation cycle.
      
      Another approach would be to override `read_attribute_for_serialization` inside
      Active Record to force the definition of attribute methods:
      
         def read_attribute_for_serialization(attribute)
           self.class.define_attribute_methods
           send(attribute)
         end
      
      Unfortunately, this is quite likely going to cause a performance degradation.
      
      This patch therefore restores the behaviour from the 4-0-stable branch by
      explicitly forcing the class to define its attribute methods in a similar spot
      (when records are initialized). This should not cause any extra roundtrips to
      the database because the `@columns` should already be cached on the class.
      
      Fixes #15188.
      2d73f5ae
  3. 08 5月, 2014 1 次提交
  4. 19 4月, 2014 1 次提交
  5. 13 4月, 2014 1 次提交
  6. 11 4月, 2014 3 次提交
  7. 10 4月, 2014 1 次提交
  8. 29 3月, 2014 1 次提交
  9. 14 3月, 2014 1 次提交
  10. 28 2月, 2014 1 次提交
  11. 19 2月, 2014 1 次提交
  12. 18 2月, 2014 1 次提交
  13. 06 2月, 2014 1 次提交
    • E
      Add config to disable schema dump after migration · 8806768e
      Emil Soman 提交于
      * Add a config on Active Record named `dump_schema_after_migration`
      * Schema dump doesn't happen if the config is set to false
      * Set default value of the config to true
      * Set config in generated production environment file to false
      * Update configuration guide
      * Update CHANGELOG
      8806768e
  14. 02 2月, 2014 1 次提交
    • R
      Make arel methods private API · cd93d717
      Rafael Mendonça França 提交于
      Since its conception arel was made to be private API of Active Record.
      If users want to use arel features directly we should provide a way
      using the Active Record API without exposing the arel implementation.
      cd93d717
  15. 30 1月, 2014 1 次提交
  16. 23 1月, 2014 1 次提交
  17. 19 1月, 2014 1 次提交
    • 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
  18. 10 1月, 2014 1 次提交
    • S
      Ensure Active Record connection consistency · 6cc03675
      schneems 提交于
      Currently Active Record can be configured via the environment variable `DATABASE_URL` or by manually injecting a hash of values which is what Rails does, reading in `database.yml` and setting Active Record appropriately. Active Record expects to be able to use `DATABASE_URL` without the use of Rails, and we cannot rip out this functionality without deprecating. This presents a problem though when both config is set, and a `DATABASE_URL` is present. Currently the `DATABASE_URL` should "win" and none of the values in `database.yml` are used. This is somewhat unexpected to me if I were to set values such as `pool` in the `production:` group of `database.yml` they are ignored.
      
      There are many ways that active record initiates a connection today:
      
      - Stand Alone (without rails)
        - `rake db:<tasks>`
        - ActiveRecord.establish_connection
       
      - With Rails
        - `rake db:<tasks>`
        - `rails <server> | <console>`
        - `rails dbconsole`
      
      
      We should make all of these behave exactly the same way. The best way to do this is to put all of this logic in one place so it is guaranteed to be used.
      
      Here is my prosed matrix of how this behavior should work:
      
      ```
      No database.yml
      No DATABASE_URL
      => Error
      ```
      
      ```
      database.yml present
      No DATABASE_URL
      => Use database.yml configuration
      ```
      
      ```
      No database.yml
      DATABASE_URL present
      => use DATABASE_URL configuration
      ```
      
      ```
      database.yml present
      DATABASE_URL present
      => Merged into `url` sub key. If both specify `url` sub key, the `database.yml` `url`
         sub key "wins". If other paramaters `adapter` or `database` are specified in YAML,
         they are discarded as the `url` sub key "wins".
      ```
      
      ### Implementation
      
      Current implementation uses `ActiveRecord::Base.configurations` to resolve and merge all connection information before returning. This is achieved through a utility class: `ActiveRecord::ConnectionHandling::MergeAndResolveDefaultUrlConfig`.
      
      To understand the exact behavior of this class, it is best to review the behavior in activerecord/test/cases/connection_adapters/connection_handler_test.rb though it should match the above proposal.
      6cc03675
  19. 02 1月, 2014 1 次提交
    • J
      Automatically maintain test database schema · ff7ab3bc
      Jon Leighton 提交于
      * Move check from generated helper to test_help.rb, so that all
        applications can benefit
      * Rather than just raising when the test schema has pending migrations,
        try to load in the schema and only raise if there are pending
        migrations afterwards
      * Opt out of the check by setting
        config.active_record.maintain_test_schema = false
      * Deprecate db:test:* tasks. The test helper is now fully responsible
        for maintaining the test schema, so we don't need rake tasks for this.
        This is also a speed improvement since we're no longer reloading the
        test database on every call to "rake test".
      ff7ab3bc
  20. 04 12月, 2013 1 次提交
  21. 27 11月, 2013 1 次提交
  22. 10 11月, 2013 1 次提交
  23. 03 11月, 2013 1 次提交
  24. 28 9月, 2013 1 次提交
  25. 23 9月, 2013 1 次提交
  26. 22 9月, 2013 1 次提交
  27. 19 9月, 2013 3 次提交
  28. 11 9月, 2013 1 次提交
  29. 02 8月, 2013 2 次提交
  30. 24 7月, 2013 1 次提交
  31. 05 7月, 2013 2 次提交
  32. 03 7月, 2013 2 次提交
  33. 02 7月, 2013 1 次提交