| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Follow up of #28453.
|
|
|
|
|
|
|
|
|
|
| |
This fixes CI failure due to 48f3be8c.
`Enumerable#uniq` was introduced since Ruby 2.4. We should delegate
`uniq` to `records` explicitly.
And since b644964b `ActiveRecord::Relation` includes `Enumerable` so
delegating `map` is unneeded.
|
|\
| |
| | |
Allow order to be given expressions as hash keys
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When `order` is given a hash, the keys are currently assumed to be
attribute names and are quoted as such in the query, which makes it
impossible to pass an expression instead:
Post.order("LENGTH(title)" => :asc).last
# SELECT `posts`.* FROM `posts` ORDER BY `posts`.`LENGTH(title)` DESC LIMIT 1
If the key is an `Arel::Nodes::SqlLiteral`, we now use it directly in
the query. This provides a way to build a relation with a complex order
clause that can still be reversed with `reverse_order` or `last`.
|
|\ \
| | |
| | |
| | | |
Drop comments from structure.sql in postgresql
|
| | | |
|
| | |
| | |
| | |
| | | |
Fixes #28153.
|
| | |
| | |
| | |
| | |
| | | |
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
|