| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
or deadlocks
|
| |\
| |
| |
| | |
Add `ActiveRecord::ValueTooLong` exception class
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
Raises when #reverse_order can not process SQL order instead of making
invalid SQL before this patch
|
| |/
|
|
| |
Follow up to #22642.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The focus of this change is to make the API more accessible.
References to method and classes should be linked to make it easy to
navigate around.
This patch makes exzessiv use of `rdoc-ref:` to provide more readable
docs. This makes it possible to document `ActiveRecord::Base#save` even
though the method is within a separate module
`ActiveRecord::Persistence`. The goal here is to bring the API closer to
the actual code that you would write.
This commit only deals with Active Record. The other gems will be
updated accordingly but in different commits. The pass through Active
Record is not completely finished yet. A follow up commit will change
the spots I haven't yet had the time to update.
/cc @fxn
|
| |
|
|
|
|
| |
This change allows to instantiate all ActiveRecordError descendant
execption classes without arguments, which might be useful in testing
and is far less surprising than mandatory arguments.
|
| |
|
|
|
|
|
|
| |
Closes #21304.
While we can validate uniqueness for record without primary key on
creation, there is no way to exclude the current record when
updating. (The update itself will need a primary key to work correctly).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ActiveRecord::RecordNotFound modified to store model name, primary_key
and id of the caller model. It allows the catcher of this exception to make
a better decision to what to do with it. For example consider this simple
example:
class SomeAbstractController < ActionController::Base
rescue_from ActiveRecord::RecordNotFound, with: :redirect_to_404
private def redirect_to_404(e)
return redirect_to(posts_url) if e.model == 'Post'
raise
end
end
|
| |
|
|
|
|
|
| |
When `AR::Base.save!` or `AR::Base.destroy!` is called and an exception
is raised, the exception doesn't have any error message or has a weird
message like `#<FailedBulb:0x0000000907b4b8>`. Give a better message so
we can easily understand why it's failing to save/destroy.
|
| |
|
|
|
|
|
|
|
|
| |
The name `ActiveModel::AttributeAssignment::UnknownAttributeError` is
too implementation specific so let's move the constant directly under
the ActiveModel namespace.
Also since this constant used to be under the ActiveRecord namespace, to
make the upgrade path easier, let's avoid raising the former constant
when we deal with this error on the Active Record side.
|
| |
|
|
|
|
| |
`ActiveModel::AttributesAssignment`
Allows to use it for any object as an includable module.
|
| |
|
|
|
|
| |
Since 3e30c5d, it started ignoring the given error message. This commit
changes the behavior of AR::RecordNotSaved#initialize so that it no
longer loses the given error message.
|
| |
|
|
| |
attribute.
|
| |
|
|
| |
This allows these exceptions to be handled generically in conjunction with RecordInvalid.
|
| |\
| |
| |
| | |
Message on AR::UnknownAttributeError should include the class name of a record
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This would be helpful if 2 models have an attribute that has a similar
name to the other. e.g:
before:
User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
# => ActiveRecord::UnknownAttributeError: unknown attribute: name
after:
User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
# => ActiveRecord::UnknownAttributeError: unknown attribute on User: name
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This would be helpful if 2 models have an attribute that has a similar
name to the other. e.g:
before:
User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
# => ActiveRecord::UnknownAttributeError: unknown attribute: name
after:
User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
# => ActiveRecord::UnknownAttributeError: unknown attribute on User: name
|
| | |
|
| |
|
|
|
| |
variables [ci skip]
Thanks to @matthewd for the excellent feedback! :heart:
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
* Clarify what the situation is and what to do.
* Advise loading schema using `rake db:setup` instead of migrating.
* Use a rescue in the initializer rather than extending the error
message in-place.
* Preserve the original backtrace of other errors by using `raise`
rather than raising again with `raise error`.
References 0ec45cd15d0a2f5aebc75e23d841b6c12f3ba763
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently if you attempt to use a database that does not exist you get an error:
```
PG::ConnectionBad FATAL: database "db_error" does not exist
```
The solution is easy, create and migrate your database however new developers may not know these commands by memory. Instead of requiring the developer to search for a solution, tell them how to fix the problem in the error message:
```
ActiveRecord::NoDatabase: FATAL: database "db_error" does not exist
Run `$ bin/rake db:create db:migrate` to create your database
```
Active Record should not know about `rake db:migrate` so this additional information needs to come from the railtie. Potential alternative implementation suggestions are welcome.
|
| | |
|
| |\
| |
| | |
Rather than raising ThrowResult when construct_limited_ids_conditions comes up empty, set the relation to NullRelation and rely on its results.
|
| | |
| |
| |
| |
| |
| | |
up empty, set the relation to NullRelation and rely on its results.
This will help avoid errors like 2fcafee250ee2, because in most cases NullRelation will do the right thing. Minor bonus is avoiding the use of exceptions for flow control.
|
| |/
|
|
|
|
|
|
|
| |
begin
Topic.new("hello" => "world")
rescue ActiveRecord::UnknownAttributeError => e
e.record # => #<Topic ... >
e.attribute # => "hello"
end
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If your database supports setting the isolation level for a transaction,
you can set it like so:
Post.transaction(isolation: :serializable) do
# ...
end
Valid isolation levels are:
* `:read_uncommitted`
* `:read_committed`
* `:repeatable_read`
* `:serializable`
You should consult the documentation for your database to understand the
semantics of these different levels:
* http://www.postgresql.org/docs/9.1/static/transaction-iso.html
* https://dev.mysql.com/doc/refman/5.0/en/set-transaction.html
An `ActiveRecord::TransactionIsolationError` will be raised if:
* The adapter does not support setting the isolation level
* You are joining an existing open transaction
* You are creating a nested (savepoint) transaction
The mysql, mysql2 and postgresql adapters support setting the
transaction isolation level. However, support is disabled for mysql
versions below 5, because they are affected by a bug
(http://bugs.mysql.com/bug.php?id=39170) which means the isolation level
gets persisted outside the transaction.
|
| |
|
|
| |
SQLite3 driver to correctly generate a time column instead of datetime
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
An association between two models cannot be made if a relevant key is
unknown, so fail fast rather than generating invalid SQL. Fixes #3207.
|
| |
|
|
| |
This reverts commit ee2be435b1e5c0e94a4ee93a1a310e0471a77d07.
|
| |
|
|
|
| |
If we don't have a primary key when we ask for it, it's better to fail
fast. Fixes GH #2307.
|
| | |
|
| | |
|
| |
|
|
| |
's/[ \t]*$//' -i {} \;)
|
| | |
|
| | |
|
