aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/cases/adapters/postgresql
Commit message (Collapse)AuthorAgeFilesLines
* Change the empty block style to have space inside of the blockRafael Mendonça França2018-09-251-1/+1
|
* Enable `Performance/UnfreezeString` copyuuji.yaginuma2018-09-232-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Ruby 2.3 or later, `String#+@` is available and `+@` is faster than `dup`. ```ruby # frozen_string_literal: true require "bundler/inline" gemfile(true) do source "https://rubygems.org" gem "benchmark-ips" end Benchmark.ips do |x| x.report('+@') { +"" } x.report('dup') { "".dup } x.compare! end ``` ``` $ ruby -v benchmark.rb ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux] Warming up -------------------------------------- +@ 282.289k i/100ms dup 187.638k i/100ms Calculating ------------------------------------- +@ 6.775M (± 3.6%) i/s - 33.875M in 5.006253s dup 3.320M (± 2.2%) i/s - 16.700M in 5.032125s Comparison: +@: 6775299.3 i/s dup: 3320400.7 i/s - 2.04x slower ```
* `supports_xxx?` returns whether a feature is supported by the backendRyuta Kamizono2018-09-081-8/+0
| | | | Rather than a configuration on the connection.
* Merge pull request #32647 from eugeneius/lazy_transactionsMatthew Draper2018-08-232-1/+4
|\ | | | | Omit BEGIN/COMMIT statements for empty transactions
| * Omit BEGIN/COMMIT statements for empty transactionsEugene Kenny2018-08-132-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a transaction is opened and closed without any queries being run, we can safely omit the `BEGIN` and `COMMIT` statements, as they only exist to modify the connection's behaviour inside the transaction. This removes the overhead of those statements when saving a record with no changes, which makes workarounds like `save if changed?` unnecessary. This implementation buffers transactions inside the transaction manager and materializes them the next time the connection is used. For this to work, the adapter needs to guard all connection use with a call to `materialize_transactions`. Because of this, adapters must opt in to get this new behaviour by implementing `supports_lazy_transactions?`. If `raw_connection` is used to get a reference to the underlying database connection, the behaviour is disabled and transactions are opened eagerly, as we can't know how the connection will be used. However when the connection is checked back into the pool, we can assume that the application won't use the reference again and reenable lazy transactions. This prevents a single `raw_connection` call from disabling lazy transactions for the lifetime of the connection.
* | Add database configuration to disable advisory locks.Guo Xiang Tan2018-08-221-0/+8
|/ | | | https://github.com/rails/rails/issues/31190
* PostgreSQL 10 new relkind for partitioned tables (#31336)Yannick Schutz2018-07-271-0/+22
| | | | | | | | | | | | | | | | | | | | | | | * PostgreSQL 10 new relkind for partitioned tables Starting with PostgreSQL 10, we can now have partitioned tables natively * Add comment * Remove extra space * Add test for partition table in postgreSQL10 * Select 'p' for "BASE TABLE" and add a test case to support PostgreSQL 10 partition tables * Address RuboCop offense * Addressed incorrect `postgresql_version` Fixes #33008. [Yannick Schutz & Yasuo Honda & Ryuta Kamizono]
* OS X -> macOS [Closes #30313]Xavier Noria2018-06-231-1/+1
| | | | [Jon Moss & Xavier Noria]
* Parse raw value only when a value came from user in numericality validatorRyuta Kamizono2018-05-281-1/+4
| | | | | | | | Since `parse_raw_value_as_a_number` may not always parse raw value from database as a number without type casting (e.g. "$150.55" as money format). Fixes #32531.
* Make force equality checking more strictly not to allow serialized attributeRyuta Kamizono2018-05-251-0/+6
| | | | | | | | | | | Since #26074, introduced force equality checking to build a predicate consistently for both `find` and `create` (fixes #27313). But the assumption that only array/range attribute have subtype was wrong. We need to make force equality checking more strictly not to allow serialized attribute. Fixes #32761.
* Fix `CustomCops/AssertNot` to allow it to have failure messageRyuta Kamizono2018-05-132-3/+3
| | | | Follow up of #32605.
* Remove unnecessary `respond_to?(:report_on_exception)` checkingyuuji.yaginuma2018-03-021-2/+2
| | | | Since Rails 6 requires Ruby 2.4.1+.
* Fix `#columsn_for_distinct` of MySQL and PostgreSQLkg8m2018-02-271-10/+10
| | | | | | | 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/+18
| | | | | | | | | 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-232-0/+63
| | | | | | | | | | | | | | 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.
* Deprecate update_attributes and update_attributes!Eddie Lebow2018-02-171-2/+2
| | | | Closes #31998
* Dump correctly index nulls order for postgresqlfatkodima2018-01-282-0/+34
|
* Use assert_predicate and assert_not_predicateDaniel Colson2018-01-2517-61/+61
|
* Change refute to assert_notDaniel Colson2018-01-252-3/+3
|
* Use respond_to test helpersDaniel Colson2018-01-251-1/+1
|
* Merge pull request #31422 from Edouard-chin/multistatement-fixturesMatthew Draper2018-01-241-1/+3
|\ | | | | Build a multi-statement query when inserting fixtures
| * Build a multi-statement query when inserting fixtures:Edouard CHIN2018-01-221-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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-221-0/+109
| |
* | Correctly handle infinity value in PostgreSQL range typeyuuji.yaginuma2018-01-041-0/+12
| | | | | | | | | | | | | | | | 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
* | Suppress `warning: BigDecimal.new is deprecated` in activerecordYasuo Honda2017-12-134-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `BigDecimal.new` has been deprecated in BigDecimal 1.3.3 which will be a default for Ruby 2.5. Refer https://github.com/ruby/bigdecimal/commit/533737338db915b00dc7168c3602e4b462b23503 ``` $ cd rails/activerecord/ $ git grep -l BigDecimal.new | grep \.rb | xargs sed -i -e "s/BigDecimal.new/BigDecimal/g" ``` - Changes made only to Active Record. Will apply the same change to other module once this commit is merged. - The following deprecation has not been addressed because it has been reported at `ActiveRecord::Result.new`. `ActiveRecord::Result.ancestors` did not show `BigDecimal`. * Not addressed ```ruby /path/to/rails/activerecord/lib/active_record/connection_adapters/mysql/database_statements.rb:34: warning: BigDecimal.new is deprecated ``` * database_statements.rb:34 ```ruby ActiveRecord::Result.new(result.fields, result.to_a) if result ``` * ActiveRecord::Result.ancestors ```ruby [ActiveRecord::Result, Enumerable, ActiveSupport::ToJsonWithActiveSupportEncoder, Object, Metaclass::ObjectMethods, Mocha::ObjectMethods, PP::ObjectMixin, ActiveSupport::Dependencies::Loadable, ActiveSupport::Tryable, JSON::Ext::Generator::GeneratorMethods::Object, Kernel, BasicObject] ``` This commit has been tested with these Ruby and BigDecimal versions - ruby 2.5 and bigdecimal 1.3.3 ``` $ ruby -v ruby 2.5.0dev (2017-12-14 trunk 61217) [x86_64-linux] $ gem list |grep bigdecimal bigdecimal (default: 1.3.3, default: 1.3.2) ``` - ruby 2.4 and bigdecimal 1.3.0 ``` $ ruby -v ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-linux-gnu] $ gem list |grep bigdecimal bigdecimal (default: 1.3.0) ``` - ruby 2.3 and bigdecimal 1.2.8 ``` $ ruby -v ruby 2.3.5p376 (2017-09-14 revision 59905) [x86_64-linux] $ gem list |grep -i bigdecimal bigdecimal (1.2.8) ``` - ruby 2.2 and bigdecimal 1.2.6 ``` $ ruby -v ruby 2.2.8p477 (2017-09-14 revision 59906) [x86_64-linux] $ gem list |grep bigdecimal bigdecimal (1.2.6) ```
* | Suppress expected exceptions by `report_on_exception` = `false` in Ruby 2.5Yasuo Honda2017-12-131-0/+2
|/ | | | | | | | | | | | | * Ruby 2.4 introduces `report_on_exception` to control if it reports exceptions in thread, this default value has been `false` in Ruby 2.4. Refer https://www.ruby-lang.org/en/news/2016/11/09/ruby-2-4-0-preview3-released/ * Ruby 2.5 changes `report_on_exception` default value to `true` since this commit https://svn.ruby-lang.org/cgi-bin/viewvc.cgi?revision=61183&view=revision This pull request suppresses expected exceptions by setting `report_on_exception` = `false` it also supports Ruby 2.3 which does not have`report_on_exception`.
* Refactor `length`, `order`, and `opclass` index options dumpingRyuta Kamizono2017-12-031-3/+3
|
* Add support for PostgreSQL operator classes to add_indexGreg Navis2017-11-303-5/+40
| | | | | | | | | | | | 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}
* Add new error class `QueryCanceled` which will be raised when canceling ↵Ryuta Kamizono2017-11-271-2/+29
| | | | | | | | | | | | | | | statement due to user request (#31235) This changes `StatementTimeout` to `QueryCanceled` for PostgreSQL. In MySQL, errno 1317 (`ER_QUERY_INTERRUPTED`) is only used when the query is manually cancelled. But in PostgreSQL, `QUERY_CANCELED` error code (57014) which is used `StatementTimeout` is also used when the both case. And, we can not tell which reason happened. So I decided to introduce new error class `QueryCanceled` closer to the error code name.
* Rename `TransactionTimeout` to more descriptive `LockWaitTimeout` (#31223)Ryuta Kamizono2017-11-271-2/+2
| | | | | | Since #31129, new error class `StatementTimeout` has been added. `TransactionTimeout` is caused by the timeout shorter than `StatementTimeout`, but its name is too generic. I think that it should be a name that understands the difference with `StatementTimeout`.
* Merge pull request #30980 from sobrinho/sobrinho/arel-star-ignored-columnsRafael França2017-11-131-8/+8
|\ | | | | Do not use `Arel.star` when `ignored_columns`
| * Change tests to use models which don't ignore any columnsJon Moss2017-11-131-8/+8
| |
* | Add new error class `StatementTimeout` which will be raised when statement ↵Ryuta Kamizono2017-11-131-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | timeout exceeded (#31129) We are sometimes using The MAX_EXECUTION_TIME hint for MySQL depending on the situation. It will prevent catastrophic performance down by wrong performing queries. The new error class `StatementTimeout` will make to be easier to handle that case. https://dev.mysql.com/doc/refman/5.7/en/optimizer-hints.html#optimizer-hints-execution-time
* | Raise `TransactionTimeout` when lock wait timeout exceeded for PG adapterRyuta Kamizono2017-11-111-0/+29
| | | | | | | | Follow up of #30360.
* | removed unnecessary semicolonsShuhei Kitagawa2017-10-281-1/+1
|/
* `supports_extensions?` return always true since PostgreSQL 9.1Yasuo Honda2017-10-244-454/+440
| | | | | | | | since the minimum version of PostgreSQL currently Rails supports is 9.1, there is no need to handle if `supports_extensions?` Refer https://www.postgresql.org/docs/9.1/static/sql-createextension.html "CREATE EXTENSION"
* Remove deprecated argument `name` from `#indexes`Rafael Mendonça França2017-10-231-1/+1
|
* Fix longer sequence name detection for serial columns (#28339)Ryuta Kamizono2017-10-151-0/+32
| | | | | | | | We already found the longer sequence name, but we could not consider whether it was the sequence name created by serial type due to missed a max identifier length limitation. I've addressed the sequence name consideration to respect the max identifier length. Fixes #28332.
* `Postgres::OID::Range` serializes to a `Range`, quote in `Quoting`Thomas Cannon2017-09-262-1/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PostgreSQL 9.1+ introduced range types, and Rails added support for using this datatype in ActiveRecord. However, the serialization of `PostgreSQL::OID::Range` was incomplete, because it did not properly quote the bounds that make up the range. A clear example of this is a `tsrange`. Normally, ActiveRecord quotes Date/Time objects to include the milliseconds. However, the way `PostgreSQL::OID::Range` serialized its bounds, the milliseconds were dropped. This meant that the value was incomplete and not equal to the submitted value. An example of normal timestamps vs. a `tsrange`. Note how the bounds for the range do not include their milliseconds (they were present in the ruby Range): UPDATE "iterations" SET "updated_at" = $1, "range" = $2 WHERE "iterations"."id" = $3 [["updated_at", "2017-09-23 17:07:01.304864"], ["range", "[2017-09-23 00:00:00 UTC,2017-09-23 23:59:59 UTC]"], ["id", 1234]] `PostgreSQL::OID::Range` serialized the range by interpolating a string for the range, which works for most cases, but does not work for timestamps: def serialize(value) if value.is_a?(::Range) from = type_cast_single_for_database(value.begin) to = type_cast_single_for_database(value.end) "[#{from},#{to}#{value.exclude_end? ? ')' : ']'}" else super end end (byebug) from = type_cast_single_for_database(value.begin) 2010-01-01 13:30:00 UTC (byebug) to = type_cast_single_for_database(value.end) 2011-02-02 19:30:00 UTC (byebug) "[#{from},#{to}#{value.exclude_end? ? ')' : ']'}" "[2010-01-01 13:30:00 UTC,2011-02-02 19:30:00 UTC)" @sgrif (the original implementer for Postgres Range support) provided some feedback about where the quoting should occur: Yeah, quoting at all is definitely wrong here. I'm not sure what I was thinking in 02579b5, but what this is doing is definitely in the wrong place. It should probably just be returning a range of subtype.serialize(value.begin) and subtype.serialize(value.end), and letting the adapter handle the rest. `Postgres::OID::Range` now returns a `Range` object, and `ActiveRecord::ConnectionAdapters::PostgreSQL::Quoting` can now encode and quote a `Range`: def encode_range(range) "[#{type_cast(range.first)},#{type_cast(range.last)}#{range.exclude_end? ? ')' : ']'}" end ... encode_range(range) #=> "['2010-01-01 13:30:00.670277','2011-02-02 19:30:00.745125')" This commit includes tests to make sure the milliseconds are preserved in `tsrange` and `tstzrange` columns
* Fix collided sequence name detectionRyuta Kamizono2017-09-181-0/+36
| | | | | | If collided named sequence already exists, newly created serial column will generate alternative sequence name. Fix sequence name detection to allow the alternative names.
* Add an extra assertion to ensure dumping schema default as expectedRyuta Kamizono2017-09-081-1/+4
|
* Fix `quote_default_expression` for UUID with array defaultRyuta Kamizono2017-09-081-0/+10
| | | | Fixes #30539.
* Prevent extra `SET time zone` in `configure_connection` (#28413)Ryuta Kamizono2017-08-211-0/+7
| | | | | | | | `SET time zone 'value'` is an alias for `SET timezone TO 'value'`. https://www.postgresql.org/docs/current/static/sql-set.html So if `variables["timezone"]` is specified, it is enough to `SET timezone` once.
* Allow `serialize` with a custom coder on `json` and `array` columnsRyuta Kamizono2017-08-131-1/+25
| | | | | | | We already have a test case for `serialize` with a custom coder in `PostgresqlHstoreTest`. https://github.com/rails/rails/blob/v5.1.3/activerecord/test/cases/adapters/postgresql/hstore_test.rb#L316-L335
* Move `test_not_compatible_with_serialize_macro` to `JSONSharedTestCases`Ryuta Kamizono2017-08-111-11/+2
| | | | Because `JSONSharedTestCases` is also used for `Mysql2JSONTest`.
* Merge pull request #29520 from kirs/serialize-vs-postgres-native-columnSean Griffin2017-08-042-0/+18
|\ | | | | Do not let use `serialize` on native JSON/array column
| * Do not let use `serialize` on native JSON/array columnKir Shatrov2017-08-042-0/+18
| |
* | Merge remote-tracking branch 'origin/master' into unlock-minitestRafael Mendonça França2017-08-0142-20/+112
|\|
| * Merge pull request #29869 from kamipo/make_type_map_to_privateRafael França2017-07-212-7/+7
| |\ | | | | | | Make `type_map` to private because it is only used in the connection adapter
| | * Make `type_map` to private because it is only used in the connection adapterRyuta Kamizono2017-07-202-7/+7
| | | | | | | | | | | | | | | | | | | | | `type_map` is an internal API and it is only used in the connection adapter. And also, some type map initializer methods requires passed `type_map`, but those instances already has `type_map` in itself. So we don't need explicit passing `type_map` to the initializers.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-07 16:11:51 +0000