| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
This follows up d97980a16d76ad190042b4d8578109714e9c53d0.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently several queries cannot return correct result due to incorrect
`RangeError` handling.
First example:
```ruby
assert_equal true, Topic.where(id: [1, 9223372036854775808]).exists?
assert_equal true, Topic.where.not(id: 9223372036854775808).exists?
```
The first example is obviously to be true, but currently it returns
false.
Second example:
```ruby
assert_equal topics(:first), Topic.where(id: 1..9223372036854775808).find(1)
```
The second example also should return the object, but currently it
raises `RecordNotFound`.
It can be seen from the examples, the queries including large number
assuming empty result is not always correct.
Therefore, This change handles `RangeError` to generate executable SQL
instead of raising `RangeError` to users to always return correct
result. By this change, it is no longer raised `RangeError` to users.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently we sometimes find a redundant begin block in code review
(e.g. https://github.com/rails/rails/pull/33604#discussion_r209784205).
I'd like to enable `Style/RedundantBegin` cop to avoid that, since
rescue/else/ensure are allowed inside do/end blocks in Ruby 2.5
(https://bugs.ruby-lang.org/issues/12906), so we'd probably meets with
that situation than before.
|
|
|
|
|
|
|
|
|
| |
* Arel: Implemented DB-aware NULL-safe comparison
* Fixed where clause inversion for NULL-safe comparison
* Renaming "null_safe_eq" to "is_not_distinct_from", "null_safe_not_eq" to "is_distinct_from"
[Dmytro Shteflyuk + Rafael Mendonça França]
|
|
|
|
|
| |
When one relation is merged into another that has a different base class
merging `from_clause` causes invalid SQL to be generated
|
|
|
|
|
|
|
|
|
| |
MySQL supports JOINs to UPDATE, so if column name isn't qualified by
table name, it would cause an ambiguous error:
```
Mysql2::Error: Column 'integer' in field list is ambiguous: UPDATE `pets` INNER JOIN `toys` ON `toys`.`pet_id` = `pets`.`pet_id` SET `integer` = COALESCE(`integer`, 0) + 1 WHERE `toys`.`name` = ?
```
|
|
|
|
|
|
|
|
| |
`relations_test.rb`
`persistence_test.rb` and `relations_test.rb` have too many lines, so
I'd like to extract relation around tests to dedicated files before
newly test added.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `Relation::Merger` has a problem that order values would be merged
as nested array.
That was caused an issue #33664 since if array value is passed to
`order` and first element in the array includes `?`, the array is
regarded as a prepared statement and bind variables.
https://api.rubyonrails.org/classes/ActiveRecord/Sanitization/ClassMethods.html#method-i-sanitize_sql_for_order
Just merging that as splat args like other values would fix the issue.
Fixes #33664.
|
| |
|
|
|
|
|
|
| |
Adds test case for failing issue
Moves set_value back to protected
|
| |
|
|
|
|
| |
effect the arel and the arel may already be generated by fresh_when
|
|
|
|
|
| |
It makes to ease to detect a future regression as long as the methods
are covered by this test.
|
| |
|
|\
| |
| |
| |
| | |
mohsen-alizadeh/sanitize_empty_and_nil_parameters_passed_to_select
sanitize empty and nil parameters to select #31059
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Most of the time the table and predicate_builder
passed to Relation.new are exactly the
arel_table and predicate builder of the
given klass. This uses klass.arel_table
and klass.predicate_builder as the defaults,
so we don't have to pass them in most cases.
This does change the signaure of both Relation and
AssocationRelation. Are we ok with that?
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`BigDecimal.new` has been deprecated in BigDecimal 1.3.3
which will be a default for Ruby 2.5.
Refer https://github.com/ruby/bigdecimal/commit/533737338db915b00dc7168c3602e4b462b23503
```
$ cd rails/activerecord/
$ git grep -l BigDecimal.new | grep \.rb | xargs sed -i -e "s/BigDecimal.new/BigDecimal/g"
```
- Changes made only to Active Record. Will apply the same change to
other module once this commit is merged.
- The following deprecation has not been addressed because it has been
reported at `ActiveRecord::Result.new`. `ActiveRecord::Result.ancestors`
did not show `BigDecimal`.
* Not addressed
```ruby
/path/to/rails/activerecord/lib/active_record/connection_adapters/mysql/database_statements.rb:34:
warning: BigDecimal.new is deprecated
```
* database_statements.rb:34
```ruby
ActiveRecord::Result.new(result.fields, result.to_a) if result
```
* ActiveRecord::Result.ancestors
```ruby
[ActiveRecord::Result,
Enumerable,
ActiveSupport::ToJsonWithActiveSupportEncoder,
Object,
Metaclass::ObjectMethods,
Mocha::ObjectMethods,
PP::ObjectMixin,
ActiveSupport::Dependencies::Loadable,
ActiveSupport::Tryable,
JSON::Ext::Generator::GeneratorMethods::Object,
Kernel,
BasicObject]
```
This commit has been tested with these Ruby and BigDecimal versions
- ruby 2.5 and bigdecimal 1.3.3
```
$ ruby -v
ruby 2.5.0dev (2017-12-14 trunk 61217) [x86_64-linux]
$ gem list |grep bigdecimal
bigdecimal (default: 1.3.3, default: 1.3.2)
```
- ruby 2.4 and bigdecimal 1.3.0
```
$ ruby -v
ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-linux-gnu]
$ gem list |grep bigdecimal
bigdecimal (default: 1.3.0)
```
- ruby 2.3 and bigdecimal 1.2.8
```
$ ruby -v
ruby 2.3.5p376 (2017-09-14 revision 59905) [x86_64-linux]
$ gem list |grep -i bigdecimal
bigdecimal (1.2.8)
```
- ruby 2.2 and bigdecimal 1.2.6
```
$ ruby -v
ruby 2.2.8p477 (2017-09-14 revision 59906) [x86_64-linux]
$ gem list |grep bigdecimal
bigdecimal (1.2.6)
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reported at https://travis-ci.org/rails/rails/jobs/274370258
- `Post.find([1, 2])` generates this query below:
```sql
SELECT "posts".* FROM "posts" WHERE "posts"."id" IN ($1, $2) [["id", 1], ["id", 2]]
```
- `Post.where(id: 1).or(Post.where(id: 2)).to_a` generates this query below:
```sql
SELECT "posts".* FROM "posts" WHERE ("posts"."id" = $1 OR "posts"."id" = $2) [["id", 1], ["id", 2]]
```
Most of the time these two queries return the same result but the order of records are not guaranteed
from SQL point of view then added `sort` before comparing them.
|
|\
| |
| | |
Delegate :rindex, :slice, :rotate(missing) to 'records'
|
| | |
|
| |
| |
| | |
Context: https://github.com/rails/rails/pull/29619#discussion_r125158589
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`:authors` has a foreign key to `:author_addresses`.
If only `:authors` fixture loaded into the database which supports
foreign key and checks the existing data when enabling foreien keys
like Oracle, it raises the following error
`ORA-02298: cannot validate (ARUNIT.FK_RAILS_94423A17A3) - parent keys not found`
It is because there is no parent data exists in `author_addresses` table.
Here are how other database with foreign key support works:
- MySQL does not check the existing data when enabling foreign key by `foreign_key_checks=1`
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_foreign_key_checks
> Setting foreign_key_checks to 1 does not trigger a scan of the existing table data. Therefore, rows added to the table while foreign_key_checks=0 will not be verified for consistency.
- PostgreSQL database itself has a feature to check existing data when
enabling foreign key and discussed at #27636, which is reverted.
|
|
|
|
|
|
|
|
|
|
|
| |
`where.not` with multiple conditions is still unexpected behavior. But
`where.not` with only polymorphic association has already been fixed in
213796fb.
Closes #14161.
Closes #16983.
Closes #17010.
Closes #26207.
|
|
|
|
|
|
| |
has many association wrong set of primary key and foreign key are selected.
Changed code to use 'join' primary key and foreign key over 'association' primary key and foreign key.
|
| |
|
|
|
|
|
| |
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
|
|
|
|
| |
`bind_values` was removed from Arel
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A common source of bugs and code bloat within Active Record has been the
need for us to maintain the list of bind values separately from the AST
they're associated with. This makes any sort of AST manipulation
incredibly difficult, as any time we want to potentially insert or
remove an AST node, we need to traverse the entire tree to find where
the associated bind parameters are.
With this change, the bind parameters now live on the AST directly.
Active Record does not need to know or care about them until the final
AST traversal for SQL construction. Rather than returning just the SQL,
the Arel collector will now return both the SQL and the bind parameters.
At this point the connection adapter will have all the values that it
had before.
A bit of this code is janky and something I'd like to refactor later. In
particular, I don't like how we're handling associations in the
predicate builder, the special casing of `StatementCache::Substitute` in
`QueryAttribute`, or generally how we're handling bind value replacement
in the statement cache when prepared statements are disabled.
This also mostly reverts #26378, as it moved all the code into a
location that I wanted to delete.
/cc @metaskills @yahonda, this change will affect the adapters
Fixes #29766.
Fixes #29804.
Fixes #26541.
Close #28539.
Close #24769.
Close #26468.
Close #26202.
There are probably other issues/PRs that can be closed because of this
commit, but that's all I could find on the first few pages.
|
|\
| |
| | |
Use frozen-string-literal in ActiveRecord
|
| | |
|
|/
|
|
|
|
|
|
| |
This reverts commit b6ad4052d18e4b29b8a092526c2beef013e2bf4f.
This is not something that the majority of Active Record should be
testing or care about. We should look at having fewer places rely on
these details, not make it easier to rely on them.
|
|
|
|
|
| |
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]
|
|
|
|
|
| |
`FakeKlass` in `relation_test.rb` and `relation/mutation_test.rb` are
almost the same.
|
|
|
|
|
|
|
|
|
|
|
| |
The `find_each`, `find_in_batches` and `in_batches` APIs usually operate
on large numbers of records, where it's preferable not to load them all
into memory at once.
If the query cache is enabled, it will hold onto the query results until
the end of the execution context (request/job), which means the memory
used is still proportional to the total number of records. These queries
are typically not repeated, so the query cache isn't desirable here.
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Remove unused defined association
|
| |
| |
| |
| |
| | |
`belongs_to :developer` on `Comment` model was added in 431f8e0 but it
is unused.
|
|/ |
|