Support Descending Indexes for MySQL #28773
Conversation
kamipo
force-pushed
the
support_descending_indexes
branch
from
665e146
to
75fd542
Compare
| table, name, | ||
| unique = false, | ||
| columns = [], | ||
| lengths: {}, |
There was a problem hiding this comment.
Why use keyword arguments for only some of the fields?
There was a problem hiding this comment.
These keyword arguments are optional, not always used by any adapters.
There was a problem hiding this comment.
I'm probably just missing something, but why are we making this change in the PR?
There was a problem hiding this comment.
I sometimes hit the incorrect initializing value issue (e.g. in #26745).
lengths and orders should be initialized as a Hash. But now these are initialized as [] in mysql2 and postgresql adapters, nil in sqlite3 adater (for the reason, we use index.lengths.present? instead of index.lengths.any?).
https://github.com/rails/rails/blob/v5.1.0.rc1/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb#L338
https://github.com/rails/rails/blob/v5.1.0.rc1/activerecord/lib/active_record/connection_adapters/postgresql/schema_statements.rb#L143
https://github.com/rails/rails/blob/v5.1.0.rc1/activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb#L313
https://github.com/rails/rails/blob/v5.1.0.rc1/activerecord/lib/active_record/schema_dumper.rb#L188-L189
I hit the issue again in this change. I thought that the issue is related thing in this change. But if we prefer to separate the fixing issue, I can create new PR that fixing the issue, then rebase this PR on master once the PR has merged.
| @@ -2,6 +2,41 @@ module ActiveRecord | |||
| module ConnectionAdapters | |||
| module SQLite3 | |||
| module SchemaStatements # :nodoc: | |||
| # Returns an array of indexes for the given table. | |||
There was a problem hiding this comment.
Can we put this method back where it was? I know it's technically supposed to be here, but it shouldn't be moved in this commit/PR (unrelated to adding support for something in MySQL)
There was a problem hiding this comment.
Should I separate a commit/PR that refactoring indexes (changing IndexDefinition, consistent placed, and tiny tweaks) in this commit/PR?
There was a problem hiding this comment.
Yep, I guess a separate commit in the PR is fine. My preference would be to leave things the way they are, since, just as an example, moving #indexes for the SQLite3 adapter is kind of a cosmetic change, which we generally try and avoid 😢
* Use keyword arguments in `IndexDefinition` to ease to ignore unused options and to avoid to initialize incorrect empty value. * Place it in `SchemaStatements` for consistency. * And tiny tweaks.
MySQL 8.0.1 and higher supports descending indexes: `DESC` in an index definition is no longer ignored. See https://dev.mysql.com/doc/refman/8.0/en/descending-indexes.html.
kamipo
force-pushed
the
support_descending_indexes
branch
from
75fd542
to
606830d
Compare
MySQL 8.0.1 and higher supports descending indexes:
DESCin an indexdefinition is no longer ignored.
See https://dev.mysql.com/doc/refman/8.0/en/descending-indexes.html.