| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This was causing an infinity loop since it was delegating to `all` and
all delegating back to this module.
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
bogdanvlviv/remove-ability-update-locking_column-value
Remove ability update locking_column value
|
| | | | | | |
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Use it to specify that an association should be initialized with a
particular record before validation. For example:
# Before
belongs_to :account
before_validation -> { self.account ||= Current.account }
# After
belongs_to :account, default: -> { Current.account }
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
`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
```
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
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
```
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
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
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
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.
|