aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/cases/primary_keys_test.rb
Commit message (Collapse)AuthorAgeFilesLines
* PERF: 20% faster pk attribute accessRyuta Kamizono2019-04-221-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've realized that `user.id` is 20% slower than `user.name` in the benchmark (https://github.com/rails/rails/pull/35987#issuecomment-483882480). The reason that performance difference is that `self.class.primary_key` method call is a bit slow. Avoiding that method call will make almost attribute access faster and `user.id` will be completely the same performance with `user.name`. Before (02b5b8cb): ``` Warming up -------------------------------------- user.id 140.535k i/100ms user['id'] 96.549k i/100ms user.name 158.110k i/100ms user['name'] 94.507k i/100ms user.changed? 19.003k i/100ms user.saved_changes? 25.404k i/100ms Calculating ------------------------------------- user.id 2.231M (± 0.9%) i/s - 11.243M in 5.040066s user['id'] 1.310M (± 1.3%) i/s - 6.565M in 5.012607s user.name 2.683M (± 1.2%) i/s - 13.439M in 5.009392s user['name'] 1.322M (± 0.9%) i/s - 6.615M in 5.003239s user.changed? 201.999k (±10.9%) i/s - 1.007M in 5.091195s user.saved_changes? 258.214k (±17.1%) i/s - 1.245M in 5.007421s ``` After (this change): ``` Warming up -------------------------------------- user.id 158.364k i/100ms user['id'] 106.412k i/100ms user.name 158.644k i/100ms user['name'] 107.518k i/100ms user.changed? 19.082k i/100ms user.saved_changes? 24.886k i/100ms Calculating ------------------------------------- user.id 2.768M (± 1.1%) i/s - 13.936M in 5.034957s user['id'] 1.507M (± 2.1%) i/s - 7.555M in 5.017211s user.name 2.727M (± 1.5%) i/s - 13.643M in 5.004766s user['name'] 1.521M (± 1.3%) i/s - 7.634M in 5.018321s user.changed? 200.865k (±11.1%) i/s - 992.264k in 5.044868s user.saved_changes? 269.652k (±10.5%) i/s - 1.344M in 5.077972s ```
* SQLite 3.7.16+ returns the order of the primary key columnsYasuo Honda2018-11-251-2/+0
| | | | | | | | https://www.sqlite.org/releaselog/3_7_16.html > 9 Enhance the PRAGMA table_info command so that the "pk" column is an increasing integer to show the order of columns in the primary key. Rails 6 supports SQLite 3.8 then we can remove this skip condition.
* SQLite: Don't leak internal schema objectsRyuta Kamizono2018-07-091-0/+1
| | | | | | | | | | | | | | Related #31201. If creating custom primary key (like a string) in SQLite, it would also create an internal index implicitly which named begin with "sqlite_". It need to be hidden since the internal object names are reserved and prohibited for public use. See https://www.sqlite.org/fileformat2.html#intschema Fixes #33320.
* Use assert_predicate and assert_not_predicateDaniel Colson2018-01-251-9/+9
|
* Reset schema cache after testyuuji.yaginuma2017-12-101-0/+2
| | | | | | | | | | | | | | | Currently, `test_copy_table_with_composite_primary_keys` test fails depending on execution order. The reproduction step is as follows. ``` $ ARCONN=sqlite3_mem bin/test -w -n "/^(?:CalculationsTest#(?:test_#skip_query_cache\\!_for_a_simple_calculation)|PrimaryKeyAnyTypeTest#(?:test_any_type_primary_key)|ActiveRecord::ConnectionAdapters::SQLite3AdapterTest#(?:test_copy_table_with_composite_primary_keys))$/" --seed 41545 ``` The column info is cached by `PrimaryKeyAnyTypeTest#test_any_type_primary_key`, and the test seems to have failed due to the influence. So clear cache after testing so as not to affect other tests. Related: https://travis-ci.org/rails/rails/jobs/313730163#L1788
* Remove deprecated method `supports_primary_key?`Rafael Mendonça França2017-10-231-4/+0
|
* Should quote composite primary key namesRyuta Kamizono2017-09-041-1/+11
| | | | | | | Otherwise using reserved words as composite primary key names will be failed as an invalid SQL. Fixes #30518.
* Prefer to place a table options before `force: :cascade` (#28005)Ryuta Kamizono2017-08-271-3/+3
| | | | | | 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`.
* Merge remote-tracking branch 'origin/master' into unlock-minitestRafael Mendonça França2017-08-011-0/+2
|\
| * Use frozen-string-literal in ActiveRecordKir Shatrov2017-07-191-0/+2
| |
* | Merge branch 'master' into unlock-minitestKasper Timm Hansen2017-07-151-5/+18
|\|
| * 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
| |
| * Don't map id to primary key in raw_write_attributeEugene Kenny2017-06-151-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The `raw_write_attribute` method is used to update a record's attributes to reflect the new state of the database in `update_columns`. The hash provided to `update_columns` is turned into an UPDATE query directly, which means passing an `id` key results in an update to the `id` column, even if the model uses a different attribute as its primary key. When updating the record, we don't want to apply the `id` column change to the primary key attribute, since that's not what happened in the query. Without the code to handle this case, `write_attribute_with_type_cast` no longer contains any logic shared between `raw_write_attribute` and `write_attribute`, so we can inline the code into those two methods.
| * Avoid overwriting the methods of `AttributeMethods::PrimaryKey`Ryuta Kamizono2017-06-071-5/+12
| | | | | | | | | | | | | | | | | | Currently the methods of `AttributeMethods::PrimaryKey` are overwritten by `define_attribute_methods`. It will be broken if a table that customized primary key has non primary key id column. It should not be overwritten if a table has any primary key. Fixes #29350.
* | Don't use same table between primary_keys tests and composite_primary_keys testsPrathamesh Sonpatki2017-04-261-7/+7
|/ | | | | | | | | | | - The test `PrimaryKeyAnyTypeTest#test_any_type_primary_key` was failing if ran after running all tests from `CompositePrimaryKeyTest`. - This was happening because `CompositePrimaryKeyTest` was changing the primary key of the barcodes table which was cached in schema cache. - As we were always going to drop the `barcodes` table at the end of tests in both `PrimaryKeyTest` and `CompositePrimaryKeyTest`, solved this issue by using different table name for tests in `CompositePrimaryKeyTest`.
* Merge pull request #28029 from koic/empty_insert_statement_value_not_supportedMatthew Draper2017-04-041-0/+2
|\ | | | | Raise NotImplementedError when using empty_insert_statement_value with Oracle
| * Raise NotImplementedError when using empty_insert_statement_value with OracleKoichi ITO2017-02-171-0/+2
| | | | | | | | Refer: https://github.com/rsim/oracle-enhanced/pull/1180
* | Correctly dump native timestamp types for MySQLRyuta Kamizono2017-02-231-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The native timestamp type in MySQL is different from datetime type. Internal representation of the timestamp type is UNIX time, This means that timestamp columns are affected by time zone. ``` > SET time_zone = '+00:00'; Query OK, 0 rows affected (0.00 sec) > INSERT INTO time_with_zone(ts,dt) VALUES (NOW(),NOW()); Query OK, 1 row affected (0.02 sec) > SELECT * FROM time_with_zone; +---------------------+---------------------+ | ts | dt | +---------------------+---------------------+ | 2016-02-07 22:11:44 | 2016-02-07 22:11:44 | +---------------------+---------------------+ 1 row in set (0.00 sec) > SET time_zone = '-08:00'; Query OK, 0 rows affected (0.00 sec) > SELECT * FROM time_with_zone; +---------------------+---------------------+ | ts | dt | +---------------------+---------------------+ | 2016-02-07 14:11:44 | 2016-02-07 22:11:44 | +---------------------+---------------------+ 1 row in set (0.00 sec) ```
* | Add CHANGELOG entry for #27384 and #27762Ryuta Kamizono2017-02-171-4/+4
|/
* Deprecate `supports_primary_key?`Ryuta Kamizono2017-02-121-11/+13
| | | | | | | | | | | | `supports_primary_key?` was added to determine if `primary_key` is implemented in the adapter in f060221. But we already use `primary_key` without `supports_primary_key?` (207f266, 5f3cf42) and using `supports_primary_key?` has been removed in #1318. This means that `supports_primary_key?` is no longer used in the internal and Active Record doesn't work without `primary_key` is implemented (all adapters must implement `primary_key`). Closes #27977
* Fix bigint primary key with unsignedRyuta Kamizono2017-02-101-11/+23
| | | | | | | Currently schema dumper lost the unsigned option when primary key is defined as bigint with unsigned. This commit fixes the issue. Closes #27960
* Fix `test_composite_primary_key_out_of_order`Ryuta Kamizono2017-02-101-2/+8
| | | | | `test_composite_primary_key_out_of_order` should use `barcodes_reverse` table.
* Simplify and speed up Postgres query for primary_keysJordan Lewis2017-02-091-0/+9
| | | | | | | | | | | | | | | | | | primary_keys(table) needs to query various metadata tables in Postgres to determine the primary key for the table. Previously, it did so using a complex common table expression against pg_constraint and pg_attribute. This patch simplifies the query by joining pg_index against pg_attribute instead of going through pg_constraint. This avoids an expensive unnest, window function query, and common table expression. EXPLAINing these queries in Postgres against a database with a single table with a composite primary key shows a 66% reduction in the plan and execute latencies. This is significant during application startup time, especially against very large schemas, where these queries would be even slower and more numerous. Closes #27949
* Fix inspection behavior when the :id column is not primary keynamusyaka2017-02-091-0/+7
|
* Restore custom primary key tests lost at #26266Ryuta Kamizono2017-02-041-25/+43
| | | | | Some custom primary key tests (added at #17631, #17696, #18220, #18228) were lost at #26266. Restore the tests to improve test coverage.
* Correctly dump integer-like primary key with default nilRyuta Kamizono2017-02-041-20/+19
| | | | | | | The PR #27384 changed integer-like primary key to be autoincrement unless an explicit default. This means that integer-like primary key is restored as autoincrement unless dumping the default nil explicitly. We should dump integer-like primary key with default nil correctly.
* Remove useless `test_supports_primary_key`Ryuta Kamizono2016-12-191-6/+0
| | | | | `supports_primary_key?` method is defined in `AbstractAdapter` so does not raise any errors.
* Merge pull request #27274 from kamipo/primary_key_with_auto_increment_and_bigintMatthew Draper2016-12-061-8/+18
|\ | | | | Make `:auto_increment` option works on `:bigint`
| * Make `:auto_increment` option works on `:bigint`Ryuta Kamizono2016-12-061-8/+18
| | | | | | | | Follow up to #27272.
* | Make pg adapter use bigserial for pk by defaultPavel Pravosud2016-12-051-0/+7
| |
* | Change MySQL and Postgresql to use Bigint primary keysJon McCartie2016-12-051-52/+29
|/
* Make `:auto_increment` to internal primary key optionRyuta Kamizono2016-12-061-0/+27
| | | | | | Using `:auto_increment` option for abstracting the DB-specific auto incremental types. It is worth to ease to implement the compatibility layer.
* Add more rubocop rules about whitespacesRafael Mendonça França2016-10-291-2/+2
|
* modernizes hash syntax in activerecordXavier Noria2016-08-061-2/+2
|
* applies new string literal convention in activerecord/testXavier Noria2016-08-061-25/+25
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Move the warning about composite primary key to `AttributeMethods::PrimaryKey`Ryuta Kamizono2016-07-021-2/+8
| | | | | | | | | | | 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.
* Merge pull request #25620 from kamipo/create_without_primary_keyRafael França2016-07-011-0/+8
|\ | | | | Pass `pk: false` to `connection.insert` explicitly if do not have a primary key
| * Pass `pk: false` to `connection.insert` explicitly if do not have a primary keyRyuta Kamizono2016-07-011-0/+8
| | | | | | | | | | | | Because causing an extra query by `sql_for_insert` for guessing a primary key. https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/connection_adapters/postgresql/database_statements.rb#L121-L125
* | Extract foreign key action from `information_schema`Ryuta Kamizono2016-06-071-12/+0
|/ | | | Fixes #25300.
* Primary key should be `NOT NULL`Ryuta Kamizono2016-03-121-1/+1
| | | | | | | Follow up to #18228. In MySQL and PostgreSQL, primary key is to be `NOT NULL` implicitly. But in SQLite it must be specified `NOT NULL` explicitly.
* Extract `default_primary_key?` to refactor `column_spec_for_primary_key`Ryuta Kamizono2016-03-111-2/+2
|
* Add a test for primary key should be not nullRyuta Kamizono2016-02-291-3/+4
|
* remove args from assert_nothing_raised in testsTara Scherner de la Fuente2016-02-221-1/+1
|
* Remove duplicated composite primary key testsRyuta Kamizono2016-02-011-1/+1
|
* Merge pull request #23345 from ↵Rafael França2016-01-301-0/+7
|\ | | | | | | | | yui-knk/warning_when_composite_primary_key_is_detected Warn if `AR.primary_key` is called for a table who has composite prim…
| * Warn if `AR.primary_key` is called for a table who has composite primary keyyui-knk2016-01-301-0/+7
| | | | | | | | | | | | | | | | If `AR.primary_key` is called for a table who has composite primary key, the method returns `nil`. This behavior sometimes generates invalid SQL. The first time developers notice to invalid SQL is when they execute SQL. This commit enables developers to know they are doing something dangerous as soon as possible.
* | There is no need to define test if a connection does not support primary_keyyui-knk2016-01-311-11/+9
|/
* Remove legacy mysql adapterAbdelkader Boudih2015-12-171-3/+3
|
* Deprecate `#table_exists?`, `#tables` and passing arguments to `#talbes`yui-knk2015-11-091-1/+1
| | | | | | | | | | Reported on #21509, how views is treated by `#tables` are differ by each adapters. To fix this different behavior, after Rails 5.0 is released, deprecate `#tables`. And `#table_exists?` would check both tables and views. To make their behavior consistent with `#tables`, after Rails 5.0 is released, deprecate `#table_exists?`.
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-03 05:32:50 +0000