1. 10 3月, 2017 1 次提交
  2. 09 3月, 2017 2 次提交
  3. 07 3月, 2017 1 次提交
    • A
      Check whether `Rails.application` defined before calling it · 9b84567f
      Andrew White 提交于
      In #27674 we changed the migration generator to generate migrations at
      the path defined in `Rails.application.config.paths` however the code
      checked for the presence of the `Rails` constant but not the
      `Rails.application` method which caused problems when using Active
      Record and generators outside of the context of a Rails application.
      
      Fixes #28325.
      9b84567f
  4. 06 3月, 2017 2 次提交
  5. 05 3月, 2017 2 次提交
  6. 04 3月, 2017 9 次提交
  7. 01 3月, 2017 1 次提交
  8. 28 2月, 2017 4 次提交
    • E
      Dupping a CollectionProxy should dup the load_target · ca8c21df
      eileencodes 提交于
      In Rails 3.2 dupping a `CollectionProxy` would dup it's `load_target` as
      well. That functionality has been broken since the release of Rails 4.0.
      I hit this in an application upgrade and wondered why duplicating a
      CollectionProxy and assigning it to a variable stopped working.
      
      When calling `dup` on a `CollectionProxy` only the owner (ex.
      topic) was getting duplicated and the `load_target` would remain in tact
      with it's original object ID. Dupping the `load_target` is useful for performing
      a logging operation after records have been destroyed in a method.
      
      For example:
      
      ```
      def transfer_operation
        saved_replies = topic.replies
      
        topic.replies.clear
      
        saved_replies.each do |reply|
          user.update_replies_count!
        end
      end
      ```
      
      This change adds a `initialize_dup` method that performs a `deep_dup` on
      the `@associatiation` so that the `load_target` is dupped as well.
      
      Fixes #17117
      ca8c21df
    • R
      `valid_type?` should accept only supported types · a3b16b95
      Ryuta Kamizono 提交于
      `valid_type?` is used in schema dumper to determine if a type is
      supported. So if `valid_type?(:foobar)` is true, it means that schema
      dumper is allowed to create `t.foobar`. But it doesn't work. I think
      that `valid_type?` should accept only supported types.
      
      https://github.com/rails/rails/blob/v5.1.0.beta1/activerecord/lib/active_record/schema_dumper.rb#L135-L142
      
      ```ruby
        columns.each do |column|
          raise StandardError, "Unknown type '#{column.sql_type}' for column '#{column.name}'" unless @connection.valid_type?(column.type)
          next if column.name == pk
          type, colspec = @connection.column_spec(column)
          tbl.print "    t.#{type} #{column.name.inspect}"
          tbl.print ", #{format_colspec(colspec)}" if colspec.present?
          tbl.puts
        end
      ```
      a3b16b95
    • R
      `create_join_table` should respect `references` column type · 310dc5dc
      Ryuta Kamizono 提交于
      Follow up of #26266.
      
      The default type of `primary_key` and `references` were changed to
      `bigint` since #26266. But `create_join_table` column type is still
      `integer`. It should respect `references` column type.
      310dc5dc
    • R
      Use `tables` instead of `data_sources - views` · 1fd36cc5
      Ryuta Kamizono 提交于
      `tables` returns only tables now.
      1fd36cc5
  9. 27 2月, 2017 2 次提交
  10. 26 2月, 2017 9 次提交
  11. 25 2月, 2017 1 次提交
    • R
      Soft-deprecate the top-level HashWithIndifferentAccess class · e690a92b
      Robin Dupret 提交于
      Since using a `ActiveSupport::Deprecation::DeprecatedConstantProxy`
      would prevent people from inheriting this class and extending it
      from the `ActiveSupport::HashWithIndifferentAccess` one would break
      the ancestors chain, that's the best option we have here.
      e690a92b
  12. 24 2月, 2017 5 次提交
  13. 23 2月, 2017 1 次提交
    • R
      Correctly dump native timestamp types for MySQL · 50552633
      Ryuta Kamizono 提交于
      The native timestamp type in MySQL is different from datetime type.
      Internal representation of the timestamp type is UNIX time, This means
      that timestamp columns are affected by time zone.
      
      ```
      > SET time_zone = '+00:00';
      Query OK, 0 rows affected (0.00 sec)
      
      > INSERT INTO time_with_zone(ts,dt) VALUES (NOW(),NOW());
      Query OK, 1 row affected (0.02 sec)
      
      > SELECT * FROM time_with_zone;
      +---------------------+---------------------+
      | ts                  | dt                  |
      +---------------------+---------------------+
      | 2016-02-07 22:11:44 | 2016-02-07 22:11:44 |
      +---------------------+---------------------+
      1 row in set (0.00 sec)
      
      > SET time_zone = '-08:00';
      Query OK, 0 rows affected (0.00 sec)
      
      > SELECT * FROM time_with_zone;
      +---------------------+---------------------+
      | ts                  | dt                  |
      +---------------------+---------------------+
      | 2016-02-07 14:11:44 | 2016-02-07 22:11:44 |
      +---------------------+---------------------+
      1 row in set (0.00 sec)
      ```
      50552633