aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/schema_dumper.rb
Commit message (Collapse)AuthorAgeFilesLines
* MySQL: Fix schema dumping `enum` and `set` columns correctlyRyuta Kamizono2019-07-051-1/+5
| | | | | | | | | `enum` and `set` are typed cast as `:string`, but currently the `:string` type is incorrectly reused for schema dumping. A cast type on columns is not always the same with `sql_type`, this fixes schema dumping `enum` and `set` columns to use `sql_type` instead of `type` correctly.
* Except `table_name` from column objectsRyuta Kamizono2019-04-081-0/+5
| | | | | | | | | The `table_name` was added at #23677 to detect whether serial column or not correctly. We can do that detection before initialize column object, it makes column object size smaller, and it probably helps column object de-duplication.
* Update schema.rb documentation [CI SKIP]Derek Prior2018-04-241-5/+5
| | | | | | | | | | | | | | | | | | | | | The documentation previously claimed that `db/schema.rb` was "the authoritative source for your database schema" while simultaneously also acknowledging that the file is generated. These two statements are incongruous and the guides accurately call out that many database constructs are unsupported by `schema.rb`. This change updates the comment at the top of `schema.rb` to remove the assertion that the file is authoritative. The documentation also previously referred vaguely to "issues" when re-running old migrations. This has been updated slightly to hint at the types of problems that one can encounter with old migrations. In sum, this change attempts to more accurately capture the pros, cons, and shortcomings of the two schema formats in the guides and in the comment at the top of `schema.rb`. [Derek Prior & Sean Griffin] Co-authored-by: Sean Griffin <sean@seantheprogrammer.com>
* Remove `ForeignKeys` module which was introduced at #32299Ryuta Kamizono2018-04-021-1/+1
| | | | | | | 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.
* Move fk_ignore_pattern from config.active_record to SchemaDumperDavid Stosik2018-03-221-0/+6
| | | | | This makes more sense, as the foreign key ignore pattern is only used by the schema dumper.
* Expose foreign key name ignore pattern in configurationDavid Stosik2018-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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`.
* Refactor migration to move migrations paths to connectioneileencodes2018-01-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Refactor `length`, `order`, and `opclass` index options dumpingRyuta Kamizono2017-12-031-3/+11
|
* Add support for PostgreSQL operator classes to add_indexGreg Navis2017-11-301-0/+1
| | | | | | | | | | | | 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}
* Implement `PostgreSQL::SchemaDumper#extensions`Yasuo Honda2017-10-251-9/+1
| | | | | | | 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.
* Prefer to place a table options before `force: :cascade` (#28005)Ryuta Kamizono2017-08-271-2/+1
| | | | | | 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`.
* Remove unused returning value `stream`Ryuta Kamizono2017-08-241-2/+0
|
* Refactor `SchemaDumper` to make it possible to adapter specific customizationRyuta Kamizono2017-08-221-3/+3
| | | | | | | 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.
* Allow `table_name_prefix` and `table_name_suffix` have `$`Yasuo Honda2017-08-041-1/+3
| | | | | | | | | | | | | | | | | | | 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]
* Merge pull request #29768 from janpieper/sort-enabled-extensions-in-dumpEileen M. Uchitelle2017-07-221-1/+1
|\ | | | | Sort enabled adapter extensions in schema dump
| * Sort enabled adapter extensions in schema dumpJan Pieper2017-07-121-1/+1
| | | | | | | | | | | | | | | | 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.
* | Use frozen-string-literal in ActiveRecordKir Shatrov2017-07-191-0/+2
|/
* Revert "Merge pull request #29540 from kirs/rubocop-frozen-string"Matthew Draper2017-07-021-1/+0
| | | | | This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
* Enforce frozen string in RubocopKir Shatrov2017-07-011-0/+1
|
* Use mattr_accessor default: option throughout the projectGenadi Samokovarov2017-06-031-2/+1
|
* Update SchemaDumper.ignore_tables docsGuillermo Iguaran2017-05-151-2/+2
|
* Tweaks #28678Ryuta Kamizono2017-04-091-4/+5
| | | | | | * Fix the comment on `formatted_version` * Extract `define_params` * Remove duplicated guard clause for `@version`
* use formatted number as schema versionAnton Chuchkalov2017-04-051-1/+9
|
* Use `tables` instead of `data_sources - views`Ryuta Kamizono2017-02-281-1/+1
| | | | `tables` returns only tables now.
* Add `default_index_type?` to the generic schema dumper doesn't have the ↵Ryuta Kamizono2017-02-141-1/+1
| | | | knowledge about an index type
* Omit redundant `using: :btree` for schema dumpingRyuta Kamizono2017-02-131-1/+1
|
* Add more rubocop rules about whitespacesRafael Mendonça França2016-10-291-2/+2
|
* Extract `format_colspec` to format column specRyuta Kamizono2016-10-111-9/+9
|
* Fix table comment dumpingRyuta Kamizono2016-10-111-1/+1
| | | | | | | | | | | | | Follow up to #26735. If `table_options` returns `{ comment: nil }`, `create_table` line is broken. Example: ```ruby create_table "accounts", force: :cascade, do |t| ```
* `name` is not a column optionRyuta Kamizono2016-10-101-9/+6
| | | | `migration_keys` includes `name` but `name` is not a column option.
* Dump index options to pretty formatRyuta Kamizono2016-10-101-6/+2
| | | | | | | | | | ```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 ```
* Prevent to create blank commentRyuta Kamizono2016-10-081-3/+5
| | | | | Currently blank comment does not dump to `db/schema.rb`. But created it even if specified blank.
* Remove unnecessary `format_string`Ryuta Kamizono2016-08-231-15/+2
| | | | | `format_string` is used for standardized column types/arguments spaces. Now the standardization was removed at df84e9867219e9311aef6f4efd5dd9ec675bee5c.
* Remove the SchemaDumper options and change the default behaviorRafael Mendonça França2016-08-221-38/+3
| | | | | Now the schema dumper by default doesn't align the types and arguments in the ruby format anymore.
* Option not to line up column types and attributes in schema.rbTim Petricola2016-08-171-10/+38
|
* Add three new rubocop rulesRafael Mendonça França2016-08-161-3/+3
| | | | | | | | Style/SpaceBeforeBlockBraces Style/SpaceInsideBlockBraces Style/SpaceInsideHashLiteralBraces Fix all violations in the repository.
* applies new string literal convention in activerecord/libXavier Noria2016-08-061-5/+5
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Merge pull request #25340 from kamipo/prevent_table_comment_queryRafael França2016-07-281-4/+4
|\ | | | | Prevent `table_comment` query if a table doesn't have a comment
| * Prevent `table_comment` query if a table doesn't have a commentRyuta Kamizono2016-06-101-4/+4
| |
* | Move the warning about composite primary key to `AttributeMethods::PrimaryKey`Ryuta Kamizono2016-07-021-6/+1
|/ | | | | | | | | | | 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.
* Remove magic comment in generated `schema.rb`Ryuta Kamizono2016-05-121-4/+0
| | | | | Rails 5.0 has been dropped Ruby 1.9 support. I think no need magic comment anymore.
* Dump indexes in `create_table` for generates SQL in one queryRyuta Kamizono2016-04-201-20/+33
| | | | | If the adapter supports indexes in create table, it generates SQL in one query.
* Database comments: Treat blank comments as no comment. Don't dump blank ↵Jeremy Daer2016-04-191-1/+1
| | | | comments.
* Database comments: switch to keyword args for new table optionsJeremy Daer2016-04-181-2/+3
| | | | | | * Switch to keyword args where we can without breaking compat. * Use add_table_options! for :options, too. * Some code polish.
* Add support for specifying comments for tables, columns, and indexes.Andrey Novikov2016-04-161-0/+4
| | | | | | | | | | | | | 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
* Merge pull request #24054 from kamipo/extract_default_primary_keyRafael França2016-03-111-1/+1
|\ | | | | Extract `default_primary_key?` to refactor `column_spec_for_primary_key`
| * Extract `default_primary_key?` to refactor `column_spec_for_primary_key`Ryuta Kamizono2016-03-111-1/+1
| |
* | Initialize `column.table_name` immediately for `column.serial?` correctly ↵Ryuta Kamizono2016-03-081-4/+1
|/ | | | | | | | working Currently the results of `column.serial?` is not correct. For `column.serial?` correctly working, initialize `column.table_name` immediately.
* Revert "Dump indexes in `create_table` instead of `add_index`"Sean Griffin2016-02-051-4/+6
| | | | | | | | | | 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.
* Prevent destructive action on production databaseschneems2016-01-071-1/+1
| | | | | | | 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`.
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-16 12:30:19 +0000