| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
https://buildkite.com/rails/rails/builds/60601#81daf2ee-9259-42e5-983d-c57d66499b76/928-939
|
|
|
|
| |
This follows #35595.
|
|
|
|
| |
This is completely same with `test_last`.
|
|
|
|
| |
This covers what #34626 fixes.
|
|
|
|
|
|
|
|
| |
Since `serialize` is passed user input args (from `where`, schema
default, etc), a helper should provide `serialize` if the helper also
provide `cast`.
Related #32624, 34cc301, a741208.
|
|
|
|
|
| |
This is covered by `test_update_all_with_order_and_limit_updates_subset_only`
and `test_update_all_with_order_and_limit_and_offset_updates_subset_only`.
|
|
|
|
|
|
|
|
|
|
|
|
| |
kamipo/fix_leaking_scope_on_relation_create"
This reverts commit b67d5c6dedbf033515a96a95d24d085bf99a0d07, reversing
changes made to 2e018361c7c51e36d1d98bf770b7456d78dee68b.
Reason: #35186 may cause that silently leaking information when people
upgrade the app.
We need deprecation first before making this.
|
|
|
|
|
|
|
|
|
| |
Currently custom attributes are always qualified by the table name in
the generated SQL wrongly even if the table doesn't have the named
column, it would cause an invalid SQL error.
Custom attributes should only be qualified if the table has the same
named column.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
callbacks
`relation.create` populates scope attributes to new record by `scoping`,
it is necessary to assign the scope attributes to the record and to find
STI subclass from the scope attributes.
But the effect of `scoping` is class global, it was caused undesired
behavior that pollute all class level querying methods in initialization
block and callbacks (`after_initialize`, `before_validation`,
`before_save`, etc), which are user provided code.
To avoid the leaking scope issue, restore the original current scope
before initialization block and callbacks are invoked.
Fixes #9894.
Fixes #17577.
Closes #31526.
|
|
|
|
|
|
| |
BEGIN transaction would cause COMMIT or ROLLBACK, so unless COMMIT and
ROLLBACK aren't treated as write queries as well as BEGIN, the
`ReadOnlyError` would be raised.
|
| |
|
|
|
|
|
| |
Otherwise `save` method would raise the `ReadOnlyError` against `BEGIN`
and `ROLLBACK` queries.
|
|
|
|
|
|
|
| |
I originally named this `StatementInvalid` because that's what we do in
GitHub, but `@tenderlove` pointed out that this means apps can't test
for or explitly rescue this error. `StatementInvalid` is pretty broad so
I've renamed this to `ReadOnlyError`.
|
|
|
|
| |
See: https://travis-ci.org/rails/rails/jobs/462233144#L1384
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This PR adds the ability to prevent writes to a database even if the
database user is able to write (ie the database is a primary and not a
replica).
This is useful for a few reasons: 1) when converting your database from
a single db to a primary/replica setup - you can fix all the writes on
reads early on, 2) when we implement automatic database switching or
when an app is manually switching connections this feature can be used
to ensure reads are reading and writes are writing. We want to make sure
we raise if we ever try to write in read mode, regardless of database
type and 3) for local development if you don't want to set up multiple
databases but do want to support rw/ro queries.
This should be used in conjunction with `connected_to` in write mode.
For example:
```
ActiveRecord::Base.connected_to(role: :writing) do
Dog.connection.while_preventing_writes do
Dog.create! # will raise because we're preventing writes
end
end
ActiveRecord::Base.connected_to(role: :reading) do
Dog.connection.while_preventing_writes do
Dog.first # will not raise because we're not writing
end
end
```
|
| |
|
|
|
|
|
|
|
|
| |
Originally specified attributes were only normal values, and
`ActiveRecord::MultiparameterAssignmentErrors` did not occur.
In addition, an assertion is performed only on rescue, even if an
exception does not occur, the test passes. To avoid this use `assert_raise`.
|
|
|
|
| |
[Gannon McGibbon + Kenji Suzuki]
|
|
|
|
|
|
|
|
|
|
|
| |
`QueryAttribute#value_for_database` calls only `type.serialize`, and
`Boolean#serialize` is a no-op unlike other attribute types.
It caused the issue #32624. Whether or not `serialize` will invoke
`cast` is undefined in our test cases, but it actually does not work
properly unless it does so for now.
Fixes #32624.
|
| |
|
|
|
|
|
| |
This autocorrects the violations after adding a custom cop in
3305c78dcd.
|
|
|
|
|
|
| |
73e7aab behaved as expected on codeship, failing the build with
exactly these RuboCop violations. Hopefully `rubocop -a` will
have been enough to get a passing build!
|
|
|
|
|
|
|
|
|
| |
SQLServerAdapter (gem `activerecord-sqlserver-adapter`) uses square
brackets for quoting column names (e.g. `[id]`). Those brackets must not
be misinterpreted in regular expressions.
Failure:
Expected /SELECT [developers].[id].* FROM developers/ to match "SELECT [developers].[id], [developers].[name], [developers].[salary], [developers].[firm_id], [developers].[mentor_id], [developers].[created_at], [developers].[updated_at], [developers].[created_on], [developers].[updated_on] FROM developers".
|
| |
|
| |
|
| |
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Previously table name qualified `*` is used in that case. If it is not
qualified with a table name, an ambiguous column name error will occur
when using JOINs.
|
|
|
|
|
|
|
| |
These changes prevent ignoring environments name of which is a `Symbol`
```
config.active_record.protected_environments = ['staging', :production]
```
|
|\
| |
| | |
Quote colum_names when building select:
|
| |
| |
| |
| |
| |
| |
| |
| | |
- #30980 introcuded a change to not use `Arel.star` when model have ignored columns, a query used to look like `SELECT *. FROM developers` whereas now it would like `SELECT column1, column2 FROM developers`
- If a column has the same name has a reserved database specific keyword (such as key, where ...) then the query would fail because the names aren't quoted
- Quoting almost always happen unless we use a `from` clause in the query https://github.com/rails/rails/blob/9965b98dc0d58a86e10b4343bb6e15e01661a8c3/activerecord/lib/active_record/relation/query_methods.rb#L1052
- This PR cast all columns name to symbols in order for the quoting logic to be picked up https://github.com/rails/rails/blob/9965b98dc0d58a86e10b4343bb6e15e01661a8c3/activerecord/lib/active_record/relation/query_methods.rb#L1054-L1055
- A reproduction script can be found here https://gist.github.com/Edouard-chin/f56d464a0adcb76962afc1a9134a1536
|
|/
|
|
| |
Follow up of #31390.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a regression since Rails 4.2.
SQLite3 integer is stored in 1, 2, 3, 4, 6, or 8 bytes depending on the
magnitude of the value. Assuming default valid value as 4 bytes caused
that actual valid value in INTEGER storage class cannot be stored and
existing value cannot be found.
https://www.sqlite.org/datatype3.html
We should allow valid value in INTEGER storage class in SQLite3 to fix
the regression.
Fixes #22594.
|
|
|
|
|
|
|
|
|
|
|
| |
insensitive
i.e. Oracle database identifier is UPPERCASE unlike other databases.
```ruby
(byebug) query = Developer.all.to_sql
"SELECT \"DEVELOPERS\".\"ID\", \"DEVELOPERS\".\"NAME\", \"DEVELOPERS\".\"SALARY\", \"DEVELOPERS\".\"FIRM_ID\", \"DEVELOPERS\".\"MENTOR_ID\", \"DEVELOPERS\".\"CREATED_AT\", \"DEVELOPERS\".\"UPDATED_AT\", \"DEVELOPERS\".\"CREATED_ON\", \"DEVELOPERS\".\"UPDATED_ON\" FROM \"DEVELOPERS\""
```
|
|
|
|
|
|
|
| |
If there are any ignored columns, we will now list out all columns we
want to be returned from the database.
Includes a regression test.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
`Firm.id` is a bigint if mysql2 adapter is used, but `firm_id` is an
integer. It will cause an out of range error.
https://travis-ci.org/rails/rails/jobs/264112814#L776
https://travis-ci.org/rails/rails/jobs/264112835#L919
|
|
|
|
|
| |
The queries both `res2` and `res3` are completely the same.
And also, `assert_nothing_raised` is covered by following assertion.
|
| |
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |
|
|\
| |
| | |
Extract `NumericData` model for tests
|
| |
| |
| |
| |
| | |
To ease to find the numeric data tests, extract `NumericDataTest` to
`test/cases/numeric_data_test.rb` dedicated file.
|
| |
| |
| |
| | |
Currently `NumericData` model is defined some places.
|
| |
| |
| |
| |
| | |
This change reverted in eac6f369 but it is needed for data integrity.
See #25328.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
mtsmfm/disable-referential-integrity-without-superuser-privilege-take-2"
This reverts commit c1faca6333abe4b938b98fedc8d1f47b88209ecf, reversing
changes made to 8c658a0ecc7f2b5fc015d424baf9edf6f3eb2b0b.
See https://github.com/rails/rails/pull/27636#issuecomment-297534129
|
|\ \
| | |
| | | |
Add test for method `#attributes`
|
| | |
| | |
| | |
| | |
| | |
| | | |
ActiveRecord::AttributeMethods#attributes
Extracted from https://github.com/rails/rails/pull/28159
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
privileges (take 2)
Re-create https://github.com/rails/rails/pull/21233
eeac6151a5 was reverted (127509c071b4) because it breaks tests.
----------------
ref: 72c1557254
- We must use `authors` fixture with `author_addresses` because of its foreign key constraint.
- Tests require PostgreSQL >= 9.4.2 because it had a bug about `ALTER CONSTRAINTS` and fixed in 9.4.2.
|