| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
Deprecate `Migrator.schema_migrations_table_name`
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Since 67fba0cf `SchemaMigration` model was extracted.
Use `SchemaMigration.table_name` instead.
|
|/ / / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The `select` in `QueryMethods` is also an enumerable method.
Enumerable methods with block should delegate to `records` on
`CollectionProxy`, not `scope`.
Fixes #28348.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Extract `SchemaMigration.all_versions`
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Use `SchemaMigration.all_versions` instead of
`SchemaMigration.all.map(&:version)` to avoid to instantiate AR objects.
|
|/ / / / / /
| | | | | |
| | | | | |
| | | | | | |
Fixes #28285.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Simply use `SchemaMigration.table_name` instead.
|
|\ \ \ \ \ \ |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Related #25174.
`db:schema:load` doesn't work with subdirectories like previous
`db:migrate:status`. `Migrator.migration_files` should be used in
`assume_migrated_upto_version` to fix the issue.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
`db:migrate` supports subdirectories and have a test.
https://github.com/rails/rails/blob/v5.1.0.beta1/activerecord/test/cases/migrator_test.rb#L78-L85
But `db:migrate:status` doesn't work with subdirectories. It is due to
`Dir.foreach(path)` is not the same with `Dir["#{path}/**/[0-9]*_*.rb"]`.
I extracted `migration_files` and sharing it in the both to fix the
issue. And added tests for `db:migrate:status`.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Sharing `options` causes some unexpected behavior. If `limit: 2` is
specified, this means that 2 bytes integer for a reference id column and
2 chars string for a reference type column. Another example, if
`unsigned: true` is specified, this means that unsigned integer for a
reference id column, but a invalid option for a reference type column.
So `options` should not be shared with a reference type column.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Reflections only use their own information to create a `join_keys`
object. This means that we can call `join_keys` on a reflection object
and have it be context-free.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Scopes can only ever be *not* reflection objects when they are passed in
to the Reflection constructor. Given this fact, we can eliminate is_a
checks and an intermediate array object by just asking the reflection
object for join scopes.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
I don't think we actually need this parameter anymore. Nobody seems to
be using it.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Update `DateTime#change` to support usec and nsec
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Adding support for these options now allows us to update the
`DateTime#end_of` methods to match the equivalent `Time#end_of`
methods, e.g:
datetime = DateTime.now.end_of_day
datetime.nsec == 999999999 # => true
Fixes #21424.
|
|\ \ \ \ \ \ \ \
| |/ / / / / / /
|/| | | | | | | |
`valid_type?` should accept only supported types
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
`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
```
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Support for using `SELECT` column or expression aliases in the `HAVING`
clause isn't part of the SQL standard so it's better to whitelist the
test for adapters where we know it works and skip it on others.
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
Use `inspect` in `type_cast_for_schema` for date/time and decimal values
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Currently dumping defaults on schema is inconsistent.
Before:
```ruby
create_table "defaults", force: :cascade do |t|
t.string "string_with_default", default: "Hello!"
t.date "date_with_default", default: '2014-06-05'
t.datetime "datetime_with_default", default: '2014-06-05 07:17:04'
t.time "time_with_default", default: '2000-01-01 07:17:04'
t.decimal "decimal_with_default", default: 1234567890
end
```
After:
```ruby
create_table "defaults", force: :cascade do |t|
t.string "string_with_default", default: "Hello!"
t.date "date_with_default", default: "2014-06-05"
t.datetime "datetime_with_default", default: "2014-06-05 07:17:04"
t.time "time_with_default", default: "2000-01-01 07:17:04"
t.decimal "decimal_with_default", default: "1234567890"
end
```
|
|\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
Make required by default test for belongs_to association clearer
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Since #18937 `belongs_to` associations receive a setting to determine if
it should be or not treated as `required` by default.
While the tests were still passing, it was not evident that the
"default" behaviour for `required` could change in fuction of a setting,
that is set by default for fresh Rails5 apps, but not for upgraded
apps.
This commit try to relate them to make it clear what is the behaviour
expected when the setting is set as `true` or not set.
|
|\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
kamipo/create_join_table_respects_reference_key_type
`create_join_table` should respect `references` column type
|
| | |_|/ / / / / / /
| |/| | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
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.
|
|\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | | |
Do not evaluate :if arguments when :on is not satisfied for transaction callbacks
|
| | | | | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
I incorrectly changed behavior of `dup`. Reading the original issue I
thought that `dup` should retain the original contents of the record
and it's associations but it is in fact supposed to be a copy as if a
record had been reinitialized.
This reverts commit ca8c21df0fdbf1f03ba2f7fb16b39c3282dc1be0.
|
|\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | |
| | | | | | | | | | | | |
Use `tables` instead of `data_sources - views`
|
| | |/ / / / / / / / /
| |/| | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
`tables` returns only tables now.
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
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
|
|/ / / / / / / / / /
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Follow up #28183
|
|\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | | |
Handle non-existing $ARCONN
|
| | | | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
kamipo/use_max_identifier_length_for_index_name_length
Use `max_identifier_length` for `index_name_length`
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Actually `index_name_length` depend on `max_identifier_length`, not
always 63.
|
|\ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Fix `test_apply_distinct_in_count` failure in PG adapter
|
| | |_|_|_|_|_|_|_|_|/ /
| |/| | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
```
% ARCONN=postgresql be ruby -w -Itest test/cases/calculations_test.rb -n test_apply_distinct_in_count
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/core_ext/enumerable.rb:20: warning: method redefined; discarding old sum
Using postgresql
Run options: -n test_apply_distinct_in_count --seed 27731
F
Finished in 0.163682s, 6.1094 runs/s, 30.5470 assertions/s.
1) Failure:
CalculationsTest#test_apply_distinct_in_count [test/cases/calculations_test.rb:238]:
Expected /\ASELECT(?! DISTINCT) COUNT\(DISTINCT\b/ to match "SHOW max_identifier_length".
1 runs, 5 assertions, 1 failures, 0 errors, 0 skips
```
https://travis-ci.org/rails/rails/jobs/205493811#L1933
https://travis-ci.org/rails/rails/jobs/205496299#L1562
https://travis-ci.org/rails/rails/jobs/205514765#L1562
|
|\ \ \ \ \ \ \ \ \ \ \ \
| |_|/ / / / / / / / / /
|/| | | | | | | | | | | |
Fix `find_nth` with `limit_value`
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
If the `index` exceeds a `limit`, simply return an empty result without
querying the database.
|
|\ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Deprecate `supports_migrations?` on connection adapters
|
| | |/ / / / / / / / / /
| |/| | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
`supports_migrations?` was added at 4160b518 to determine if schema
statements (`create_table`, `drop_table`, etc) are implemented in the
adapter. But all tested databases has been supported migrations since
a4fc93c3 at least.
|