aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/connection_adapters
Commit message (Collapse)AuthorAgeFilesLines
...
| * Expose foreign key name ignore pattern in configurationDavid Stosik2018-03-192-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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`.
* | Support mysql2 0.4.x and 0.5.xAaron Stone2018-03-201-1/+1
|/
* Merge pull request #32271 from eileencodes/fix-three-tier-default-connectionEileen M. Uchitelle2018-03-161-1/+0
|\ | | | | Fix default connection handling with three-tier config
| * Fix connection handling with three-tier configeileencodes2018-03-161-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you had a three-tier config, the `establish_connection` that's called in the Railtie on load can't figure out how to access the default configuration. This is because Rails assumes that the config is the first value in the hash and always associated with the key from the environment. With a three tier config however we need to go one level deeper. This commit includes 2 changes. 1) removes a line from `resolve_all` which was parsing out the the environment from the config so instead of getting ``` { :development => { :primary => { :database => "whatever" } }, :animals => { :database => "whatever-animals" } }, etc with test / prod } ``` We'd instead end up with a config that had no attachment to it's envioronment. ``` { :primary => { :database => "whatever" } :animals => { :database => "whatever-animals" } etc - without test and prod } ``` Not only did this mean that Active Record didn't know how to establish a connection, it didn't have the other necessary configs along with it in the configs list. So fix this I removed the line that deletes these configs. The second thing this commit changes is adding this line to `establish_connection` ``` spec = spec[spec_name.to_sym] if spec[spec_name.to_sym] ``` When you have a three-tier config and don't pass any hash/symbol/env etc to `establish_connection` the resolver will automatically return both the primary and secondary (in this case animals db) configurations. We'll get an `database configuration does not specify adapter` error because AR will try to establish a connection on the `primary` key rather than the `primary` key's config. It assumes that the `development` or default env automatically will return a config hash, but with a three-tier config we actually get a key and config `primary => config`. This fix is a bit of a bandaid because it's not the "correct" way to handle this situation, but it does solve our immediate problem. The new code here is saying "if the config returned from the resolver (I know it's called spec in here but we interchange our meanings a LOT and what is returned is a three-tier config) has a key matching the "primary" spec name, grab the config from the spec and pass that to the estalbish_connection method". This works because if we pass `:animals` or a hash, or `:primary` we'll already have the correct configuration to connect with. This fixes the case where we want Rail to connect with the default connection. Coming soon is a refactoring that should eliminate the need to do this but I need this fix in order to write the multi-db rake tasks that I promised in my RailsConf submission. `@tenderlove` and I are working on the refactoring of the internals for connection management but it won't be ready for a few weeks and this issue has been blocking progress.
* | Fix multiline expression indexes for postgresql (#31621)fatkodima2018-03-161-1/+1
| |
* | Ensure that leading date is stripped by quoted_timeAndrew White2018-03-111-1/+1
| | | | | | | | | | | | | | | | In #24542, quoted_time was introduced to strip the leading date component for time columns because it was having a significant effect in mariadb. However, it assumed that the date component was always 2000-01-01 which isn't the case, especially if the source wasn't another time column.
* | Normalize date component when writing to time columnsAndrew White2018-03-111-1/+1
|/ | | | | | | | | | | | | | | For legacy reasons Rails stores time columns on sqlite as full timestamp strings. However because the date component wasn't being normalized this meant that when they were read back they were being prefixed with 2001-01-01 by ActiveModel::Type::Time. This had a twofold result - first it meant that the fast code path wasn't being used because the string was invalid and second it was corrupting the second fractional component being read by the Date._parse code path. Fix this by a combination of normalizing the timestamps on writing and also changing Active Model to be more lenient when detecting whether a string starts with a date component before creating the dummy time value for parsing.
* Deprecate `active_support/core_ext/hash/compact`yuuji.yaginuma2018-03-021-2/+0
| | | | | Ruby 2.4+ provides `Hash#compact` and `Hash#compact!` natively, so `active_support/core_ext/hash/compact` is no longer necessary.
* PostgreSQL adapter also supports bulk alter since #31331 [ci skip]yuuji.yaginuma2018-03-021-1/+1
|
* Use `delegate private: true` for `SchemaCreation`Ryuta Kamizono2018-03-022-5/+3
| | | | Duplicated method name list is no longer needed.
* Fix `#columsn_for_distinct` of MySQL and PostgreSQLkg8m2018-02-272-2/+2
| | | | | | | Prevent `ActiveRecord::FinderMethods#limited_ids_for` from using correct primary key values even if `ORDER BY` columns include other table's primary key. Fixes #28364.
* PostgreSQL: Allow BC dates like datetime consistentlyRyuta Kamizono2018-02-231-0/+3
| | | | | | | | | BC dates are supported by both date and datetime types. https://www.postgresql.org/docs/current/static/datatype-datetime.html Since #1097, new datetime allows year zero as 1 BC, but new date does not. It should be allowed even in new date consistently.
* PostgreSQL: Treat infinite values in date like datetime consistentlyRyuta Kamizono2018-02-233-1/+23
| | | | | | | | | | | | | | The values infinity and -infinity are supported by both date and timestamp types. https://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-DATETIME-SPECIAL-TABLE And also, it can not be known whether a value is infinity correctly unless cast a value. I've added `QueryAttribute#infinity?` to handle that case. Closes #27585.
* Use private attr_readerRyuta Kamizono2018-02-231-2/+1
| | | | | Since #32028, Rails 6 requires Ruby 2.3+. No longer needed workaround for Ruby 2.2 "private attribute?" warning.
* Rails 6 requires Ruby 2.3+Jeremy Daer2018-02-172-10/+2
|
* Fix frozen string concatenation by indicating that it's mutableJeremy Daer2018-02-161-1/+1
| | | | References 89bcca59e91fa9da941de890012872e8288e77b0
* Remove usage of strip_heredoc in the framework in favor of <<~Rafael Mendonça França2018-02-163-13/+9
| | | | | Some places we can't remove because Ruby still don't have a method equivalent to strip_heredoc to be called in an already existent string.
* Prefer `@connection.abandon_results!` than `@connection.next_result while ↵Ryuta Kamizono2018-02-041-1/+1
| | | | @connection.more_results?`
* Add nodoc to `migrations_paths` and `migration_context` in `AbstractAdapter`Ryuta Kamizono2018-02-041-2/+2
| | | | | | These are internally used only. [ci skip]
* Merge pull request #31814 from fatkodima/index-nulls-orderRafael França2018-01-291-2/+6
|\ | | | | Dump correctly index nulls order for PostgreSQL
| * Dump correctly index nulls order for postgresqlfatkodima2018-01-281-2/+6
| |
* | Extract `discard_remaining_results` for mysql2 adapterRyuta Kamizono2018-01-292-4/+6
| |
* | Define `supports_foreign_tables?` in AbstractAdapterYasuo Honda2018-01-281-0/+5
|/
* Bring back ability to insert zero value on primary key for fixtures (#31795)Ryuta Kamizono2018-01-263-22/+8
| | | | | | Since #29504, mysql2 adapter lost ability to insert zero value on primary key due to enforce `NO_AUTO_VALUE_ON_ZERO` disabled. That is for using `DEFAULT` on auto increment column, but we can use `NULL` instead in that case.
* Update note on MySQL index order support [ci skip]Eugene Kenny2018-01-261-1/+1
| | | | | MySQL supports descending indexes from 8.0.1 onwards: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-1.html
* Add test case for deprecated `insert_fixtures`Ryuta Kamizono2018-01-261-3/+5
| | | | Since #31422, `insert_fixtures` is deprecated.
* Make discard safe when it follows a manual disconnectMatthew Draper2018-01-251-1/+1
| | | | | | It doesn't have to do anything, but it shouldn't fail. Fixes #31766.
* Merge pull request #31773 from dinahshi/postgresql_bulk_patchMatthew Draper2018-01-241-1/+1
|\ | | | | Postgresql bulk_change_table should flatten procs array
| * Use concat to join procs arrays in bulk_change_tableDinah Shi2018-01-231-1/+1
| |
* | Merge pull request #31422 from Edouard-chin/multistatement-fixturesMatthew Draper2018-01-243-21/+114
|\ \ | | | | | | Build a multi-statement query when inserting fixtures
| * | Allow a 2 bytes margin:Edouard CHIN2018-01-231-1/+2
| | | | | | | | | | | | | | | - mysql will add a 2 bytes margin to the statement, so given a `max_allowed_packet` set to 1024 bytes, a 1024 bytes fixtures will no be inserted (mysql will throw an error) - Preventing this by decreasing the max_allowed_packet by 2 bytes when doing the comparison with the actual statement size
| * | Combine delete and insert statements in the same queryEdouard CHIN2018-01-222-13/+10
| | |
| * | Build a multi-statement query when inserting fixtures:Edouard CHIN2018-01-223-21/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - The `insert_fixtures` method can be optimized by making a single multi statement query for all fixtures having the same connection instead of doing a single query per table - The previous code was bulk inserting fixtures for a single table, making X query for X fixture files - This patch builds a single **multi statement query** for every tables. Given a set of 3 fixtures (authors, dogs, computers): ```ruby # before %w(authors dogs computers).each do |table| sql = build_sql(table) connection.query(sql) end # after sql = build_sql(authors, dogs, computers) connection.query(sql) ``` - `insert_fixtures` is now deprecated, `insert_fixtures_set` is the new way to go with performance improvement - My tests were done with an app having more than 700 fixtures, the time it takes to insert all of them was around 15s. Using a single multi statement query, it took on average of 8 seconds - In order for a multi statement to be executed, mysql needs to be connected with the `MULTI_STATEMENTS` [flag](https://dev.mysql.com/doc/refman/5.7/en/c-api-multiple-queries.html), which is done before inserting the fixtures by reconnecting to da the database with the flag declared. Reconnecting to the database creates some caveats: 1. We loose all open transactions; Inside the original code, when inserting fixtures, a transaction is open. Multple delete statements are [executed](https://github.com/rails/rails/blob/a681eaf22955734c142609961a6d71746cfa0583/activerecord/lib/active_record/fixtures.rb#L566) and finally the fixtures are inserted. The problem with this patch is that we need to open the transaction only after we reconnect to the DB otherwise reconnecting drops the open transaction which doesn't commit all delete statements and inserting fixtures doesn't work since we duplicated them (Primary key duplicate exception)... - In order to fix this problem, the transaction is now open directly inside the `insert_fixtures` method, right after we reconnect to the db - As an effect, since the transaction is open inside the `insert_fixtures` method, the DELETE statements need to be executed here since the transaction is open later 2. The same problem happens for the `disable_referential_integrity` since we reconnect, the `FOREIGN_KEY_CHECKS` is reset to the original value - Same solution as 1. , the disable_referential_integrity can be called after we reconnect to the transaction 3. When the multi statement query is executed, no other queries can be performed until we paginate over the set of results, otherwise mysql throws a "Commands out of sync" [Ref](https://dev.mysql.com/doc/refman/5.7/en/commands-out-of-sync.html) - Iterating over the set of results until `mysql_client.next_result` is false. [Ref](https://github.com/brianmario/mysql2#multiple-result-sets) - Removed the `active_record.sql "Fixture delete"` notification, the delete statements are now inside the INSERT's one - On mysql the `max_allowed_packet` is looked up: 1. Before executing the multi-statements query, we check the packet length of each statements, if the packet is bigger than the max_allowed_packet config, an `ActiveRecordError` is raised 2. Otherwise we concatenate the current sql statement into the previous and so on until the packet is `< max_allowed_packet`
* | | Support for PostgreSQL foreign tablesfatkodima2018-01-222-1/+15
| | |
* | | Merge pull request #24964 from vipulnsward/true-falseMatthew Draper2018-01-231-2/+2
|\ \ \ | | | | | | | | Don't perform unnecessary check with false, just use true/false values
| * | | Dont perform unnecessary check with false, just use true/false values for ↵Vipul A M2016-05-111-2/+2
| | | | | | | | | | | | | | | | @active on SQLite adapter.
* | | | Merge pull request #31732 from ↵Matthew Draper2018-01-191-1/+1
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | koic/enable_autocorrect_for_lint_end_alignment_cop Enable autocorrect for `Lint/EndAlignment` cop
| * | | | Enable autocorrect for `Lint/EndAlignment` copKoichi ITO2018-01-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ### Summary This PR changes .rubocop.yml. Regarding the code using `if ... else ... end`, I think the coding style that Rails expects is as follows. ```ruby var = if cond a else b end ``` However, the current .rubocop.yml setting does not offense for the following code. ```ruby var = if cond a else b end ``` I think that the above code expects offense to be warned. Moreover, the layout by autocorrect is unnatural. ```ruby var = if cond a else b end ``` This PR adds a setting to .rubocop.yml to make an offense warning and autocorrect as expected by the coding style. And this change also fixes `case ... when ... end` together. Also this PR itself is an example that arranges the layout using `rubocop -a`. ### Other Information Autocorrect of `Lint/EndAlignment` cop is `false` by default. https://github.com/bbatsov/rubocop/blob/v0.51.0/config/default.yml#L1443 This PR changes this value to `true`. Also this PR has changed it together as it is necessary to enable `Layout/ElseAlignment` cop to make this behavior.
* | | | | Refactor migration to move migrations paths to connectioneileencodes2018-01-183-4/+12
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | `create_database` should not add default charset when `collation` is givenRyuta Kamizono2018-01-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If `collation` is given without `charset`, it may generate invalid SQL. For example `create_database(:matt_aimonetti, collation: "utf8mb4_bin")`: ``` > CREATE DATABASE `matt_aimonetti` DEFAULT CHARACTER SET `utf8` COLLATE `utf8mb4_bin`; ERROR 1253 (42000): COLLATION 'utf8mb4_bin' is not valid for CHARACTER SET 'utf8' ``` In MySQL, charset is used to find the default collation. If `collation` is given explicitly, it is not necessary to give extra charset.
* | | | PostgreSQL: Allow pg-1.0 gem to be used with ActiveRecordLars Kanis2018-01-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pg-1.0.0 is just released and most Gemfiles don't restrict it's version. But the version is checked when connecting to the database, which leads to the following error: Gem::LoadError: can't activate pg (~> 0.18), already activated pg-1.0.0 See also this pg issue: https://bitbucket.org/ged/ruby-pg/issues/270/pg-100-x64-mingw32-rails-server-not-start Preparation for pg-1.0 was done in commit f28a331023fab, but the pg version constraint was not yet relaxed.
* | | | Revert commit 4ec5b0d6b4d8a57e034b1014942356e95caf47aa in favor of #28379Ryuta Kamizono2018-01-071-6/+1
| | | | | | | | | | | | | | | | | | | | Commit 4ec5b0d was for fixing the regression #18787, but #28379 fixes #18787 as well. So 4ec5b0d is no longer necessary.
* | | | Deprecate `valid_alter_table_type?` in sqlite3 adapterRyuta Kamizono2018-01-041-7/+12
| | | | | | | | | | | | | | | | | | | | This method which is used only in the internal was introduced in ac384820 and was renamed in #17579. It does not need to be exposed.
* | | | Correctly handle infinity value in PostgreSQL range typeyuuji.yaginuma2018-01-042-2/+10
| |_|/ |/| | | | | | | | | | | | | | | | | | | | An empty string is an invalid value in Ruby's range class. So need to handle `Float::INFINITY` as it is and cast it in `encode_range`. Fixes #31612
* | | Merge pull request #31331 from dinahshi/postgresql_bulk_updateMatthew Draper2018-01-032-5/+40
|\ \ \ | | | | | | | | Add bulk alter support for PostgreSQL
| * | | Add bulk alter support for PostgreSQLDinah Shi2017-12-062-5/+40
| | | |
* | | | Merge pull request #25456 from ojab/masterRyuta Kamizono2018-01-031-3/+1
|\ \ \ \ | | | | | | | | | | | | | | | Remove dormant check
| * | | | Remove dormant checkojab2016-06-211-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This check was introduced in 6edaa26 and moved through multiple refactorings. No test are broken after removal and AFAICS there is no way to trigger it.
* | | | | Fix recreating partial indexes after alter table for sqlitefatkodima2017-12-311-0/+1
| | | | |
* | | | | Make `sql_type` of primary key in SQLite to comparable with an integer (#28008)Ryuta Kamizono2017-12-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Originally I tried to add `assert_equal pk.sql_type, ref.sql_type`. But the assert failed even though the same type due to `sql_type` of primary key in SQLite is upper case. Prefer lower case like other types.
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-14 15:26:56 +0000