| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| | |
|
|\| |
|
| |
| |
| |
| |
| | |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
|
|
|
|
|
| |
- 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`.
|
|\
| |
| | |
Raise NotImplementedError when using empty_insert_statement_value with Oracle
|
| |
| |
| |
| | |
Refer: https://github.com/rsim/oracle-enhanced/pull/1180
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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)
```
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
| |
`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
|
|
|
|
|
|
|
| |
Currently schema dumper lost the unsigned option when primary key is
defined as bigint with unsigned. This commit fixes the issue.
Closes #27960
|
|
|
|
|
| |
`test_composite_primary_key_out_of_order` should use `barcodes_reverse`
table.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Some custom primary key tests (added at #17631, #17696, #18220, #18228)
were lost at #26266. Restore the tests to improve test coverage.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
`supports_primary_key?` method is defined in `AbstractAdapter` so does
not raise any errors.
|
|\
| |
| | |
Make `:auto_increment` option works on `:bigint`
|
| |
| |
| |
| | |
Follow up to #27272.
|
| | |
|
|/ |
|
|
|
|
|
|
| |
Using `:auto_increment` option for abstracting the DB-specific auto
incremental types. It is worth to ease to implement the compatibility
layer.
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Pass `pk: false` to `connection.insert` explicitly if do not have a primary key
|
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
| |
Fixes #25300.
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| | |
yui-knk/warning_when_composite_primary_key_is_detected
Warn if `AR.primary_key` is called for a table who has composite prim…
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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?`.
|
|
|
|
| |
Such as #10404, #18206.
|
|\
| |
| |
| | |
Add `unsigned` support for numeric data types in MySQL
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Example:
create_table :foos do |t|
t.integer :unsigned_integer, unsigned: true
t.bigint :unsigned_bigint, unsigned: true
t.float :unsigned_float, unsigned: true
t.decimal :unsigned_decimal, unsigned: true, precision: 10, scale: 2
end
|
|/
|
|
|
|
|
|
|
| |
Example:
create_table :barcodes, primary_key: ["region", "code"] do |t|
t.string :region
t.integer :code
end
|
|
|
|
| |
- Followup of https://github.com/rails/rails/pull/20190/.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`widgets` table is being created in `primary_keys_test.rb` for PostgreSQLAdapter, MysqlAdapter, Mysql2Adapter
and it makes test to fail earlier.
Before:
`bundle exec rake mysql2:test`
```
Finished in 127.287669s, 35.5258 runs/s, 97.8885 assertions/s.
1) Error:
PersistenceTest::SaveTest#test_save_touch_false:
ActiveModel::UnknownAttributeError: unknown attribute 'name' for #<Class:0x0000000a7d6ef0>.
/home/kd/projects/kd-rails/activerecord/lib/active_record/attribute_assignment.rb:36:in `rescue in _assign_attribute'
/home/kd/projects/kd-rails/activerecord/lib/active_record/attribute_assignment.rb:34:in `_assign_attribute'
/home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:40:in `block in _assign_attributes'
/home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:39:in `each'
/home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:39:in `_assign_attributes'
/home/kd/projects/kd-rails/activerecord/lib/active_record/attribute_assignment.rb:26:in `_assign_attributes'
/home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:33:in `assign_attributes'
/home/kd/projects/kd-rails/activerecord/lib/active_record/core.rb:293:in `initialize'
/home/kd/projects/kd-rails/activerecord/lib/active_record/inheritance.rb:61:in `new'
/home/kd/projects/kd-rails/activerecord/lib/active_record/inheritance.rb:61:in `new'
/home/kd/projects/kd-rails/activerecord/lib/active_record/persistence.rb:50:in `create!'
/home/kd/projects/kd-rails/activerecord/test/cases/persistence_test.rb:913:in `test_save_touch_false'
4522 runs, 12460 assertions, 0 failures, 1 errors, 4 skips
```
After:
`bundle exec rake mysql2:test`
```
Finished in 135.785086s, 33.3026 runs/s, 91.7774 assertions/s.
4522 runs, 12462 assertions, 0 failures, 0 errors, 4 skips
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I’m renaming all instances of `use_transcational_fixtures` to
`use_transactional_tests` and “transactional fixtures” to
“transactional tests”.
I’m deprecating `use_transactional_fixtures=`. So anyone who is
explicitly setting this will get a warning telling them to use
`use_transactional_tests=` instead.
I’m maintaining backwards compatibility—both forms will work.
`use_transactional_tests` will check to see if
`use_transactional_fixtures` is set and use that, otherwise it will use
itself. But because `use_transactional_tests` is a class attribute
(created with `class_attribute`) this requires a little bit of hoop
jumping. The writer method that `class_attribute` generates defines a
new reader method that return the value being set. Which means we can’t
set the default of `true` using `use_transactional_tests=` as was done
previously because that won’t take into account anyone using
`use_transactional_fixtures`. Instead I defined the reader method
manually and it checks `use_transactional_fixtures`. If it was set then
it should be used, otherwise it should return the default, which is
`true`. If someone uses `use_transactional_tests=` then it will
overwrite the backwards-compatible method with whatever they set.
|