| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I do not want to set the expectation that any enumerable object should
behave this way, but this case in particular comes up frequently enough
that I'm caving on this one.
Fixes #30684.
|
| | | | |
| | | |
| | | |
| | | | |
Closes #24190
|
| | | | |
| | | |
| | | |
| | | | |
Fixes #30586.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
ActiveRecord associations automatically guess the inverse associations.
But this feature does not work correctly on assoctions for STI.
For example, before this commit
```
class Post < ActiveRecord::Base
belongs_to :author
end
class SpecialPost < Post; end
class Author < ActiveRecord::Base
has_many :posts
has_many :special_posts
end
```
`author.posts.first.author` works correctly, but
`author.special_posts.first.author` does not work correctly.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Add missing backticks
Add missing *
Add missing .
|
| |\ \ \ \
| | | | |
| | | | |
| | | | | |
Ensure sum honors distinct on has_many through
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When using a has_many through relation and then summing an attribute
the distinct was not being used. This will ensure that when summing
an attribute, the number is only used once when distinct has been used.
|
| |\ \ \ \ \
| |/ / / /
|/| | | | |
Add `binary` helper method to fixtures.
|
| | | | | | |
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | | |
Light grammar fixes, and added a few backticks.
[ci skip]
|
| | | | |
| | | |
| | | |
| | | | |
And make reference to `Relation`.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Condenses the clauses that are common to both sides of the OR and put them outside, before the OR
This fix the current behavior where the number of conditions is exponential based on the number of times #or is used.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Note that the two relations must still have the same `includes` values
(which is the only time `references` actually does anything). It makes
sense for us to allow this, as `references` is called implicitly when
passing a hash to `where`.
Fixes #29411
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When generating models, we created ApplicationRecord in the default
location if no file existed there. That was annoying for people who
moved it to somewhere else in the autoload path. At this point, the
vast majority of apps should have either run the upgrade script or
generated a model since upgrading. For those that haven't the error
message after generating a new model should be helpful:
NameError: uninitialized constant ApplicationRecord
To ease friction in that case, this also adds a generator for
ApplicationRecord.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since #26972, `ORDER BY` is kept if `LIMIT` is presented for
performance. But in most SQL servers (e.g. PostgreSQL, SQL Server, etc),
`ORDER BY` expressions must appear in select list for `SELECT DISTINCT`.
We should not replace existing select list in that case.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When a has_many association is destroyed by `dependent: destroy`,
destroyed_by_association is set to the reflection, and this can be
checked in callbacks. This matches that behaviour for has_one
associations.
|
| |\ \ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Between 4.2 and 5.0 the behavior of how multiparameter attributes
interact with `_before_type_cast` changed. In 4.2 it returns the
post-type-cast value. After 5.0, it returns the hash that gets sent to
the type. This behavior is correct, but will cause an issue if you then
tried to render that value in an input like `text_field` or
`hidden_field`.
In this case, we want those fields to use the post-type-cast form,
instead of the `_before_type_cast` (the main reason it uses
`_before_type_cast` at all is to avoid losing data when casting a
non-numeric string to integer).
I've opted to modify `came_from_user?` rather than introduce a new
method for this as I want to avoid complicating that contract further,
and technically the multiparameter hash didn't come from assignment, it
was constructed internally by AR.
Close #27888.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This change was introduced by #18109. The intent of that change was to
specifically apply `unscoped`, not to allow all changes to
`current_scope` to affect the join. The idea of allowing `current_scope`
to affect joins is interesting and potentially more consistent, but has
sever problems associated with it. The fact that we're specifically
stripping out joins indicates one such problem (and potentially leads to
invalid queries).
Ultimately it's difficult to reason about what `Posts.joins(:users)`
actually means if it's affected by `User.current_scope`, and it's
difficult to specifically control what does or doesn't get added. If we
were starting from scratch, I don't think I'd have `joins` be affected
by `default_scope` either, but that's too big of a breaking change to
make at this point.
With this change, we no longer apply `current_scope` when bringing in
joins, with the singular exception of the motivating use case which
introduced this bug, which is providing a way to *opt-out* of having the
default scope apply to joins.
Fixes #29338.
|
| |/ / / /
| | | |
| | | |
| | | |
| | | | |
Post.where(id: 1).or(Post.where(id: 2)).where(foo: 3).unscope(where: :foo).where_clause.binds.map(&:value)
Would return [2, 3] instead of the expected [1,2]
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Abstract boolean serialization has been using 't' and 'f', with MySQL
overriding that to use 1 and 0.
This has the advantage that SQLite natively recognizes 1 and 0 as true
and false, but does not natively recognize 't' and 'f'.
This change in serialization requires a migration of stored boolean data
for SQLite databases, so it's implemented behind a configuration flag
whose default false value is deprecated. The flag itself can be
deprecated in a future version of Rails. While loaded models will give
the correct result for boolean columns without migrating old data,
where() clauses will interact incorrectly with old data.
While working in this area, also change the abstract adapter to use
`"TRUE"` and `"FALSE"` as quoted values and `true` and `false` for
unquoted. These are supported by PostreSQL, and MySQL remains
overriden.
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | | |
Skip query cache for in_batches and friends
|
| | | | | | |
|
| |/ / / /
| | | |
| | | |
| | | | |
The AbstractAdapter will translate all StandardErrors generated during the course of a query into ActiveRecord::StatementInvalids. Unfortunately, it'll also mangle non-database-related errors generated in ActiveSupport::Notification callbacks after the query has successfully completed. This should prevent it from translating errors from ActiveSupport::Notifications.
|
| | | | |
| | | |
| | | |
| | | | |
Fixes #28324.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Let's say you have a nested transaction and both records are saved.
Before the outer transaction closes, a rollback is performed. Previously
the record in the outer transaction would get marked as not persisted
but the inner transaction would get persisted.
```ruby
Post.transaction do
post_one.save # will get rolled back
Post.transaction(requires_new: true) do
post_two.save # incorrectly remains marked as persisted
end
raise ActiveRecord::Rollback
end
```
To fix this the PR changes transaction handling to have the child
transaction ask the parent how the records should be marked. When
there are child transactions, it will always be a SavpointTransaction
because the stack isn't empty. From there we pass the parent_transaction
to the child SavepointTransaction where we add the children to the parent
so the parent can mark the inner transaction as rolledback and thus mark
the record as not persisted.
`update_attributes_from_transaction_state` uses the `completed?` check to
correctly mark all the transactions as rolledback and the inner record as
not persisted.
```ruby
Post.transaction do
post_one.save # will get rolled back
Post.transaction(requires_new: true) do
post_two.save # with new behavior, correctly marked as not persisted
on rollback
end
raise ActiveRecord::Rollback
end
```
Fixes #29320
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`set_state` was directly setting the transaction state instance
variable. It's better to set the state via specific methods (`rollback!`
and `commit!` respectively.
While undocumented and untested, it's possible someone is using
`set_state` in their app or gem so I've added a deprecation notice to
it.
No where in the app do we use `nullify!` but I wanted to keep existing
behavior while replacing the method with a better pattern.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Active Record doesn't rely delegating to `arel` in the internal since
425f2ca. The delegation is a lower priority than delegating to `klass`,
so it is pretty unclear which method is delegated to `arel`.
For example, `bind_values` method was removed at b06f64c (a series of
changes https://github.com/rails/rails/compare/79f71d3...b06f64c). But a
relation still could respond to the method because `arel` also have the
same named method (#28976).
Removing the delegation will achieve predictable behavior.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
kamipo/fix_eager_loading_to_respect_store_full_sti_class
Fix eager loading to respect `store_full_sti_class` setting
|
| | | | | | |
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
ActiveRecord query cache is available when a connection is connected.
Therefore, query cache is unavailable when entering the ActiveRecord::Base.cache block without being connected.
```ruby
ActiveRecord::Base.cache do
Task.find(1) # access to database.
Task.find(1) # access to database. unavailable query cache
end
```
If we use query cache with batch script etc, we need to connect before that.
```ruby
Task.connection
ActiveRecord::Base.cache do
Task.find(1) # access to database.
Task.find(1) # available query cache
end
```
Before version 3.1, query cache had been enabled if a configuration was set up.
In order to solve the `DATABASE_URL` issue(#8074), ActiveRecord has checked whether a connection is connected or not.
Today, ActiveRecord.configurations respect `DATABASE_URL`.
https://github.com/rails/rails/blob/master/activerecord/lib/active_record/core.rb#L46
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
If a record was built on a HasManyThroughAssociation, then removed, and
then the record was saved, the removed record would be created anyways.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Doing `Author.joins(:posts).merge(Post.joins(:comments))` does this
`SELECT ... INNER JOIN posts ON... LEFT OUTER JOIN comments ON...`
instead of doing
`SELECT ... INNER JOIN posts ON... INNER JOIN comments ON...`.
This behavior is unexpected and makes little sense as, basically, doing
`Post.joins(:comments)` means I want posts that have comments. Turning
it to a LEFT JOIN means I want posts and join the comments data, if
any.
We can see this problem directly in the existing tests.
The test_relation_merging_with_merged_joins_as_symbols only does joins
from posts to comments to ratings while the ratings fixture isn't
loaded, but the count is non-zero.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`ActiveRecord::Persistence#touch` does not work well when optimistic
locking enabled and `locking_column`, without default value, is null in
the database.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix destroying existing object does not work well when optimistic
locking enabled and `locking column` is null in the database.
Follow 22a822e5813ef7ea9ab6dbbb670a363899a083af, #28914
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Improves the performance from O(n) to O(1).
Previously it would require 50 queries to
insert 50 fixtures. Now it takes only one query.
Disabled on sqlite which doesn't support multiple inserts.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If casted value is nil, generated SQL should be `IS NULL`. But currently
it is generated as `= NULL`. To prevent this behavior, avoid making bind
param if casted value is nil.
Fixes #28945.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
in `ActiveRecord::Calculations`
`select`, `count`, and `sum` in `Relation` are also `Enumerable` method
that can be passed block. `select` with block already doesn't take
arguments since 4fc3366. This is follow up of that.
|
| | | | |
| | | |
| | | |
| | | | |
[Vikrant Chaudhary, David Abdemoulaie, Matthew Draper]
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
* Fix indentation.
* Add backticks.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Since we have been using this `Arel::Table` since 111ccc832bc977b15af12c14e7ca078dad2d4373,
in order to properly handle queries, it's important that we properly type cast arguments.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`supports_statement_cache?` was introduced in 3.1.0.beta1 (104d0b2) for
bind parameter substitution, but it is no longer used in 3.1.0.rc1
(73ff679). Originally it should respect `prepared_statements` rather
than `supports_statement_cache?` (fd39847).
One more thing, named `supports_statement_cache?` is pretty misreading.
We have `StatementCache` and `StatementPool`. However,
`supports_statement_cache?` doesn't mean `StatementCache`, but
`StatementPool` unlike its name.
https://github.com/rails/rails/blob/v5.1.0/activerecord/lib/active_record/statement_cache.rb
https://github.com/rails/rails/blob/v5.1.0/activerecord/lib/active_record/connection_adapters/statement_pool.rb
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* Remove trailing spaces.
* Add backticks around method and command.
* Fix indentation.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | | |
Fix quoting in db:create grant all statement.
|
