Real world database schemas contain a lot of duplicated data.
Some column names like `id`, `created_at` etc can easily be repeated
hundreds of times. Same for SqlTypeMetada, most database will contain
only a limited number of possible combinations.
This result in a lot of wasted memory.
The idea here is to make these data sctructures immutable, use a registry
to substitute similar instances with pre-existing ones.
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`.
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.
`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.
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`.
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`.
`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.
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.
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.
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.
Follow up to #26266.
The default type of `primary_key` and `references` were changed to
`bigint` since #26266. But legacy migration and sqlite3 adapter should
keep its previous behavior.