| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example:
create_table :foos, id: :primary_key, limit: 8 do |t|
end
# or
create_table :foos, id: false do |t|
t.column :id, limit: 8
end
|
|
|
|
|
| |
Lowercase raw SQL has been replaced by 07b659c already. This commit
replaces everything else of raw SQL.
|
|
|
|
|
|
|
| |
`drop_table`
since 'drop table if exists' statement does not always work with some databases such as Oracle.
also Oracle drop table statement will not drop sequence objects.
|
|
|
|
| |
If it is not a default primary key, correctly dump the type and options.
|
|
|
|
|
|
|
| |
Example:
create_table :foos, id: :bigint do |t|
end
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently when we call id_was and we have a custom primary key name
Active Record will return the current value of the primary key. This
make impossible to correctly do an update operation if you change the
id.
Fixes #16413
|
|
|
|
|
|
| |
Making this change revealed several subtle bugs related to models with
no primary key, and anonymous classes. These have been fixed as well,
with regression tests added.
|
|
|
|
| |
/cc @zuhao
|
|
|
|
|
|
|
|
| |
It appears to have been used at some point in the past, but is no longer
used in any meaningful way. Whether a column is considered primary is
a property of the model, not the schema/column. This also removes the
need for yet another layer of caching of the model's schema, and we can
leave that to the schema cache.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #10410 it was noted that you can no longer create PK's with the
type of bigserial in PostgreSQL in 4.0.0.rc1. This is mostly
because the newer adapter is checking for column type with the
id column instead of just letting it pass through like it did
before.
Side effects:
You may just create a PK column of a type that you really don't
want to be your PK. As far as I can tell this was allowed in 3.2.X
and perhaps an exception should be raised if you try and do
something extremely dumb.
|
|
|
|
|
| |
This behavior was introduced since Rails 3.1 (207f266ccaaa9cd04cd2a7513ae5598c4358b510)
but the docs were still out of date.
|
| |
|
|
|
|
|
|
|
| |
We can conditional define the tests depending on the adapter or
connection.
Lets keep the skip for fail tests that need to be fixed.
|
| |
|
|
|
|
|
|
|
| |
patricksrobertson/bigserial_id_not_identifying_pk"
This reverts commit 3043d45eefc3776d5f3a9e7d212a01f99d869ef8, reversing
changes made to ca0275d36b395631725c4583db5a45c06443fdb9.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #10410 it was noted that you can no longer create PK's with the
type of bigserial in PostgreSQL in 4.0.0.rc1. This is mostly
because the newer adapter is checking for column type with the
id column instead of just letting it pass through like it did
before.
Side effects:
You may just create a PK column of a type that you really don't
want to be your PK. As far as I can tell this was allowed in 3.2.X
and perhaps an exception should be raised if you try and do
something extremely dumb.
|
|
|
|
|
| |
This reverts commit 637a7d9d357a0f3f725b0548282ca8c5e7d4af4a, reversing
changes made to 5937bd02dee112646469848d7fe8a8bfcef5b4c1.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In the end I think the pain of implementing this seamlessly was not
worth the gain provided.
The intention was that it would allow plain ruby objects that might not
live in your main application to be subclassed and have persistence
mixed in. But I've decided that the benefit of doing that is not worth
the amount of complexity that the implementation introduced.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Allows two models to use the same table but have different primary keys.
|