| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Publish AS::Executor and AS::Reloader APIs
|
| |
| |
| |
| |
| |
| | |
These should allow external code to run blocks of user code to do
"work", at a similar unit size to a web request, without needing to get
intimate with ActionDipatch.
|
|\ \
| | |
| | | |
ActiveRecord #second_to_last tests and finder methods
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | |
| | | |
samphilipd/sam/properly_deallocate_prepared_statements_outside_of_transaction
Correctly deallocate prepared statements if we fail inside a transaction
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Addresses issue #12330
Overview
========
Cached postgres prepared statements become invalidated if the schema
changes in a way that it affects the returned result.
Examples:
- adding or removing a column then doing a 'SELECT *'
- removing the foo column then doing a 'SELECT bar.foo'
In normal operation this isn't a problem, we can rescue the error,
deallocate the prepared statement and re-issue the command.
However in PostgreSQL transactions, once any command fails, the
transaction becomes 'poisoned' and any subsequent commands will raise
InFailedSQLTransaction.
This includes DEALLOCATE statements, so the default deallocation
strategy instead of removing the cached prepared statement instead
raises InFailedSQLTransaction.
Why this is bad
===============
1. InFailedSQLTransaction is a fairly cryptic error and doesn't
communicate any useful information about what has actually gone wrong.
2. In the naive implementation the prepared statement never gets
deallocated - it stays alive for the length of the session taking up
memory on the postgres server.
3. It is unsafe to retry the transaction because the bad prepared
statement is still in the cache and we would see the exact same failure
repeated.
Solution
========
If we are outside a transaction we can continue to handle these failures
gracefully in the usual way.
Inside a transaction instead of issuing a DEALLOCATE command that will
certainly fail, we now raise
ActiveRecord::PreparedStatementCacheExpired.
This can be handled further up the stack, notably inside
TransactionManager#within_new_transaction. Here we can make sure to
first rollback the transaction, then safely issue DEALLOCATE statements
to invalidate the rest of the cached prepared statements.
This also allows the user (or some gem) the opportunity to catch this error and
voluntarily retry the transaction if a schema change causes the prepared
statement cache to become invalidated.
Because the outdated statement has been deallocated, we can expect the
transaction to succeed on the second try.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When the `source_type` option is passed to a has_many through, the
resulting `Reflection` will be an instance of `PolymorphicReflection`
and not `ThroughReflection`, meaning that it will ignore the scopes that
it needs to apply from the through reflections. This adds an additional
delegation call to remedy this. I've been finding the reflection code
completely impenetrable lately, it could use some major love.
Fixes #22726
|
|\ \ \
| | | |
| | | | |
Removes potentially quadratic Regexp from ActiveRecord::LogSubscriber…
|
| | | | |
|
|\ \ \ \
| |_|_|/
|/| | |
| | | |
| | | | |
Honour joining model order in `has_many :through` associations when
eager loading
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
association when eager loading.
Previously, eager loading a `has_many :through` association with no
defined order would return the records in the natural order of the
database. Now, these records will be returned in the order that the
joining record is returned, in case there is a defined order there.
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
y-yagi/correctly_check_ApplicationRecord_in_mountable_engine
correctly check `ApplicationRecord` is exist in moutable engine
|
| | |/ /
| |/| |
| | | |
| | | | |
Follow up to 1813b29fc7632959800252f36e4b2e6ed4ac7266
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
record.id_was is nil in after_create/after_save, so we should use
id in these cases.
While this logic feels incomplete, the existing update_record uses the same
logic:
https://github.com/rails/rails/blob/2fda4e0874a97a76107ab9e88305169f2c625933/activerecord/lib/active_record/relation.rb#L83
This logic was originally added for a similar problem:
updates not working with after_create hook.
See: 482f8c15b1d699c95bfbc3d836f674a09c0d9031
Followup to #23581
Fixes #23844
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I ran into an issue where validations on a suppressed record were
causing validation errors to be thrown on a record that was never going
to be saved.
There isn't a reason to run the validations on a record that doesn't
matter.
This change moves the suppressor up the chain to be run on the `save` or
`save!` in the validations rather than in persistence. The issue with
running it when we hit persistence is that the validations are run
first, then we hit persistance, and then we hit the suppressor. The
suppressor comes first.
The change to the test was required since I added the
`validates_presence_of` validations. Adding this alone was enough to
demonstrate the issue. I added a new test to demonstrate the new
behavior is explict.
|
| | | |
| | | |
| | | |
| | | | |
Adds changelog headers for beta3 release
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I was encountered remaining `:binary_testings` table by tests failure.
When remaining `:binary_testings` table, never reach `drop_table` due to
`create_table` in the test always fails.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
I had to revert changes made for this CHANGELOG entry so this is no
longer valid. The change for this entry was removed in 2c02bc0.
|
|\ \ \ \
| | | | |
| | | | | |
`drop_table :test_text_limits` as well
|
| |/ / /
| | | |
| | | |
| | | | |
Follow up to 3b01785.
|
|\ \ \ \
| |/ / /
|/| | | |
[ci skip] Improve the readability of documents of nested_attributes
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In order to fix issue #17621 we added a check to validations that
determined if a record should be validated. Based on the existing tests
and behavior we wanted we determined the best way to do that was by
checking if `!record.peristed? || record.changed? || record.marked_for_destruction?`
This change didn't make it into a release until now. When #23790 was
opened we realized that `valid?` and `invalid?` were broken and did not
work on persisted records because of the `!record.persisted?`.
While there is still a bug that #17621 brought up, this change was too
drastic and should not be a RC blocker. I will work on fixing this so
that we don't break `valid?` but also aren't validating parent records
through child records if that parent record is validate false. This
change removes the code changes to validate and the corresponding tests.
It adds tests for two of the bugs found since Rails 5 beta2 release.
Fixes #17621
|
|\ \ \ \
| | | | |
| | | | | |
Fix issue #23625
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This resolves a bug where if the primary key used is not `id` (ex:
`uuid`), and has a `validates_uniqueness_of` in the model, a uniqueness error
would be raised. This is a partial revert of commit `119b9181ece399c67213543fb5227b82688b536f`, which introduced this behavior.
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
wisetara/wisetara/deprecate-args-ActiveSupport__TestCase#assert_nothing_raised-for-pr
Wisetara/deprecate args active support test case#assert nothing raised for pr
|
| | |/ / /
| |/| | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
creating all databases mutates the connection pool. This patch restores
the connection pool to the connection spec established before creating
all databases. Fixes #23279
|
| | | | |
| | | | |
| | | | |
| | | | | |
We are creating the table but not deleting after the test.
|
|/ / / /
| | | |
| | | |
| | | | |
A `:test_limits` table has not been created.
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
prathamesh-sonpatki/fix-showing-of-deprecation-warning-for-legacy-migrations
Correctly show deprecation warning for incompatible migrations
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
- Tests on Travis are randomly failing because schema_migrations table
does not exist in teardown block.
- Also checked that all other places where we have used
`ActiveRecord::SchemaMigration.delete_all` we have rescued it, so used
it here also. This failure was not specifically related to the test
added in this PR but to overall compatibility migration tests, so
adding as separate commit.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Once RubyGems 2.5.0 is required, then the duplicated files can be
removed, and symlinks can be used instead.
[ci skip]
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Fix `assert_in_delta` test failure
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`assert_in_delta` in `timestamp_test.rb` causes an intermittent test
failure. It looks like that caused by subseconds truncation in MySQL 5.5.
Example:
```
1) Failure:
TimestampTest#test_touching_many_attributes_updates_them [/home/travis/build/rails/rails/activerecord/test/cases/timestamp_test.rb:125]:
Expected |2016-02-06 09:22:10 +0000 - 2016-02-06 09:22:09 UTC| (1.000837185) to be <= 1.
```
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Fix NoMethodError preparable for Arel::Visitors::PostgreSQL
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
is falsy
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Add test cases about MySQL ORDER BY FIELD()
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Add assertions to MySQL `ORDER BY FIELD()` with empty data.
These tests examine to sanitize `ORDER BY FIELD()` with empty data
appropriately.
```ruby
Tag.order(['field(id, ?)', []]).to_sql
# => SELECT "tags".* FROM "tags" ORDER BY field(id, NULL)
Tag.order(['field(id, ?)', nil]).to_sql
# => SELECT "tags".* FROM "tags" ORDER BY field(id, NULL)
```
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
Remove `alias exec_without_stmt exec_query`
|