| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This was added in c24c885209ac2334dc6f798c394a821ee270bec6, removed in
b89ffe7f0047eb614e42232a21201b317b880755, and then (unintentionally?)
reintroduced in 2d7ae1b08ee2a10b12cbfeef3a6cc6da55b57df6.
|
|
|
|
|
|
|
|
|
| |
mylake/reduce-postgresql-adapter-memory-bloat"
This reverts commit 192db64452d148c7b51713979459e38407380dc6, reversing
changes made to 9893955363cf6358556ed3b36f4538d5b54e9d17.
We can't sacrifice correctness for performance.
|
|\
| |
| | |
500x memory reduction of 10k schemas for postgresql adapter
|
| |
| |
| |
| | |
bloat especially in multi-schema structure database
|
|\ \
| | |
| | | |
Extract `data_source_sql` to refactor data source statements
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
Suppress deprecation warning `implementing to_yaml is deprecated`
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Simply forward `Calculations#count` to `Enumerable#count`
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | | |
Follow up of #24203.
Since b644964b `ActiveRecord::Relation` includes `Enumerable` so it is
enough to call `super` simply.
|
|\ \ \ \
| | | | |
| | | | | |
Simply delegate `as_json` to `records`
|
| |/ / / |
|
|/ / /
| | |
| | |
| | | |
Follow up of e7381d289e4f8751dcec9553dcb4d32153bd922b.
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | | |
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
|
| | | | | | | | |
|