| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
To solve the problem #32299, just enough to introduce
`fk_ignore_pattern` option.
I don't think there is a need to expose these constants.
|
|
|
|
|
| |
This makes more sense, as the foreign key ignore pattern is only used by
the schema dumper.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When dumping the database schema, Rails will dump foreign key names only
if those names were not generate by Rails. Currently this is determined
by checking if the foreign key name is `fk_rails_` followed by
a 10-character hash.
At [Cookpad](https://github.com/cookpad), we use
[Departure](https://github.com/departurerb/departure) (Percona's
pt-online-schema-change runner for ActiveRecord migrations) to run migrations.
Often, `pt-osc` will make a copy of a table in order to run a long migration
without blocking it. In this copy process, foreign keys are copied too,
but [their name is prefixed with an underscore to prevent name collision
](https://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html#cmdoption-pt-online-schema-change-alter-foreign-keys-method).
In the process described above, we often end up with a development
database that contains foreign keys which name starts with `_fk_rails_`.
That name does not match the ignore pattern, so next time Rails dumps
the database schema (eg. when running `rake db:migrate`), our
`db/schema.rb` file ends up containing those unwanted foreign key names.
This also produces an unwanted git diff that we'd prefer not to commit.
In this PR, I'd like to suggest a way to expose the foreign key name
ignore pattern to the Rails configuration, so that individual projects
can decide on a different pattern of foreign keys that will not get
their names dumped in `schema.rb`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rails has some support for multiple databases but it can be hard to
handle migrations with those. The easiest way to implement multiple
databases is to contain migrations into their own folder ("db/migrate"
for the primary db and "db/seconddb_migrate" for the second db). Without
this you would need to write code that allowed you to switch connections
in migrations. I can tell you from experience that is not a fun way to
implement multiple databases.
This refactoring is a pre-requisite for implementing other features
related to parallel testing and improved handling for multiple
databases.
The refactoring here moves the class methods from the `Migrator` class
into it's own new class `MigrationContext`. The goal was to move the
`migrations_paths` method off of the `Migrator` class and onto the
connection. This allows users to do the following in their
`database.yml`:
```
development:
adapter: mysql2
username: root
password:
development_seconddb:
adapter: mysql2
username: root
password:
migrations_paths: "db/second_db_migrate"
```
Migrations for the `seconddb` can now be store in the
`db/second_db_migrate` directory. Migrations for the primary database
are stored in `db/migrate`".
The refactoring here drastically reduces the internal API for migrations
since we don't need to pass `migrations_paths` around to every single
method. Additionally this change does not require any Rails applications
to make changes unless they want to use the new public API. All of the
class methods from the `Migrator` class were `nodoc`'d except for the
`migrations_paths` and `migrations_path` getter/setters respectively.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for specifying non-default operator classes in PostgreSQL
indexes. An example CREATE INDEX query that becomes possible is:
CREATE INDEX users_name ON users USING gist (name gist_trgm_ops);
Previously it was possible to specify the `gist` index but not the
custom operator class. The `add_index` call for the above query is:
add_index :users, :name, using: :gist, opclasses: {name: :gist_trgm_ops}
|
|
|
|
|
|
|
| |
and abstract `SchemaDumper#extensions` is now an empty method.
Since #30337, every database adapter has its own `SchemaDumper`.
`extensions` are only supported by PostgreSQL database and postgresql database adapter.
|
|
|
|
|
|
| |
I was added a table options after `force: :cascade` in #17569 for not
touching existing tests (reducing diff). But `force: :cascade` is not an
important information. So I prefer to place a table options before
`force: :cascade`.
|
| |
|
|
|
|
|
|
|
| |
Currently `SchemaDumper` is only customizable for column options. But
3rd party connection adapters (oracle-enhanced etc) need to customizable
for table or index dumping also. To make it possible, I introduced
adapter specific `SchemaDumper` classes for that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MySQL 5.7 and PostgreSQL 9.6 allow table identifiers have the dollar sign.
* MySQL 5.7
https://dev.mysql.com/doc/refman/5.7/en/identifiers.html
> Permitted characters in unquoted identifiers:
> ASCII: [0-9,a-z,A-Z$_] (basic Latin letters, digits 0-9, dollar, underscore)
* PostgreSQL 9.6
https://www.postgresql.org/docs/9.6/static/sql-syntax-lexical.html
> SQL identifiers and key words must begin with a letter (a-z, but also letters with diacritical marks and non-Latin letters) or an underscore (_). Subsequent characters in an identifier or key word can be letters, underscores, digits (0-9), or dollar signs ($). Note that dollar signs are not allowed in identifiers according to the letter of the SQL standard, so their use might render applications less portable. The SQL standard will not define a key word that contains digits or starts or ends with an underscore, so identifiers of this form are safe against possible conflict with future extensions of the standard.
Address #30044
[Yasuo Honda & Ryuta Kamizono]
|
|\
| |
| | |
Sort enabled adapter extensions in schema dump
|
| |
| |
| |
| |
| |
| |
| |
| | |
The list of enabled adapter extensions in the schema dump isn't
sorted by default, so it may happen that the sorting changes
over time. If you're using a VCS, a change to the sorting results
in a diff without any real change. Sorting the list should solve
this problem.
|
|/ |
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
* Fix the comment on `formatted_version`
* Extract `define_params`
* Remove duplicated guard clause for `@version`
|
| |
|
|
|
|
| |
`tables` returns only tables now.
|
|
|
|
| |
knowledge about an index type
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Follow up to #26735.
If `table_options` returns `{ comment: nil }`, `create_table` line is
broken.
Example:
```ruby
create_table "accounts", force: :cascade, do |t|
```
|
|
|
|
| |
`migration_keys` includes `name` but `name` is not a column option.
|
|
|
|
|
|
|
|
|
|
| |
```ruby
# Before
t.index ["firm_id", "type", "rating"], name: "company_index", order: {"rating"=>:desc}, using: :btree
# After
t.index ["firm_id", "type", "rating"], name: "company_index", order: { rating: :desc }, using: :btree
```
|
|
|
|
|
| |
Currently blank comment does not dump to `db/schema.rb`. But created it
even if specified blank.
|
|
|
|
|
| |
`format_string` is used for standardized column types/arguments spaces.
Now the standardization was removed at df84e9867219e9311aef6f4efd5dd9ec675bee5c.
|
|
|
|
|
| |
Now the schema dumper by default doesn't align the types and arguments
in the ruby format anymore.
|
| |
|
|
|
|
|
|
|
|
| |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|\
| |
| | |
Prevent `table_comment` query if a table doesn't have a comment
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
| |
Actually schema dumper/creation supports composite primary key (#21614).
Therefore it should not show the warning about composite primary key in
connection adapter.
This change moves the warning to `AttributeMethods::PrimaryKey` and
suppress the warning for habtm join table.
Fixes #25388.
|
|
|
|
|
| |
Rails 5.0 has been dropped Ruby 1.9 support.
I think no need magic comment anymore.
|
|
|
|
|
| |
If the adapter supports indexes in create table, it generates SQL
in one query.
|
|
|
|
| |
comments.
|
|
|
|
|
|
| |
* Switch to keyword args where we can without breaking compat.
* Use add_table_options! for :options, too.
* Some code polish.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Comments are specified in migrations, stored in database itself (in its schema),
and dumped into db/schema.rb file.
This allows to generate good documentation and explain columns and tables' purpose
to everyone from new developers to database administrators.
For PostgreSQL and MySQL only. SQLite does not support comments at the moment.
See docs for PostgreSQL: http://www.postgresql.org/docs/current/static/sql-comment.html
See docs for MySQL: http://dev.mysql.com/doc/refman/5.7/en/create-table.html
|
|\
| |
| | |
Extract `default_primary_key?` to refactor `column_spec_for_primary_key`
|
| | |
|
|/
|
|
|
|
|
|
| |
working
Currently the results of `column.serial?` is not correct. For
`column.serial?` correctly working, initialize `column.table_name`
immediately.
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 99801c6a7b69eb4b006a55de17ada78f3a0fa4c1.
Ultimately it doesn't matter whether `add_index` or `t.index` are used
in the schema dumper in any meaningful way. There are gems out there
which hook into the old behavior for things like indexing materialized
views. Since the reverted commit doesn't seem to add much benefit,
there's no reason for us to break these gems.
|
|
|
|
|
|
|
| |
This PR introduces a key/value type store to Active Record that can be used for storing internal values. It is an alternative implementation to #21237 cc @sgrif @matthewd.
It is possible to run your tests against your production database by accident right now. While infrequently, but as an anecdotal data point, Heroku receives a non-trivial number of requests for a database restore due to this happening. In these cases the loss can be large.
To prevent against running tests against production we can store the "environment" version that was used when migrating the database in a new internal table. Before executing tests we can see if the database is a listed in `protected_environments` and abort. There is a manual escape valve to force this check from happening with environment variable `DISABLE_DATABASE_ENVIRONMENT_CHECK=1`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These new methods are used from the Active Record model layer to
determine which relations are viable to back a model. These new methods
allow us to change `conn.tables` in the future to only return tables and
no views. Same for `conn.table_exists?`.
The goal is to provide the following introspection methods on the
connection:
* `tables`
* `table_exists?`
* `views`
* `view_exists?`
* `data_sources` (views + tables)
* `data_source_exists?` (views + tables)
|
|\
| |
| |
| | |
Do not dump a view as a table in sqlite3, mysql and mysql2 adapters
|
| |
| |
| |
| |
| |
| | |
Now in sqlite3, mysql and mysql2 adapters, SchemaDumper dump a view as
a table. It is incorrect behavior. This change excludes a view in
schema.rb.
|