aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/arel/visitors
Commit message (Collapse)AuthorAgeFilesLines
* All of queries should return correct result even if including large numberRyuta Kamizono2019-01-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Use `unboundable?` rather than `boundable?`Ryuta Kamizono2019-01-181-4/+4
| | | | | | | | | | | | | | | | | | The `unboundable?` behaves like the `infinite?`. ```ruby inf = Topic.predicate_builder.build_bind_attribute(:id, Float::INFINITY) inf.infinite? # => 1 oob = Topic.predicate_builder.build_bind_attribute(:id, 9999999999999999999999999999999) oob.unboundable? # => 1 inf = Topic.predicate_builder.build_bind_attribute(:id, -Float::INFINITY) inf.infinite? # => -1 oob = Topic.predicate_builder.build_bind_attribute(:id, -9999999999999999999999999999999) oob.unboundable? # => -1 ```
* Enable `Lint/UselessAssignment` cop to avoid unused variable warnings (#34904)Ryuta Kamizono2019-01-093-5/+4
| | | | | | | | | | | | | | * Enable `Lint/UselessAssignment` cop to avoid unused variable warnings Since we've addressed the warning "assigned but unused variable" frequently. 370537de05092aeea552146b42042833212a1acc 3040446cece8e7a6d9e29219e636e13f180a1e03 5ed618e192e9788094bd92c51255dda1c4fd0eae 76ebafe594fc23abc3764acc7a3758ca473799e5 And also, I've found the unused args in c1b14ad which raises no warnings by the cop, it shows the value of the cop.
* Arel: Implemented DB-aware NULL-safe comparison (#34451)Dmytro Shteflyuk2018-11-1510-0/+115
| | | | | | | | | * 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]
* Merge pull request #34437 from kbrock/union_all_parenRafael Mendonça França2018-11-132-32/+19
|\ | | | | | | Fix: Arel now emits a single pair of parens for UNION and UNION ALL
| * Emit single pair of parens for UNION and UNION ALLKeenan Brock2018-11-132-32/+19
|/ | | | | | | | mysql has a great implementation to suppress multiple parens for union sql statements. This moves that functionality to the generic implementation This also introduces that functionality for UNION ALL
* Checking boundable not only `IN` clause but also `NOT IN` clauseRyuta Kamizono2018-11-031-0/+12
|
* Fix odd indentationRyuta Kamizono2018-10-101-10/+10
|
* Refactor Arel visitor to use `collect_nodes_for` as much as possibleRyuta Kamizono2018-10-101-33/+10
|
* Improve DELETE with JOIN handling to avoid subqueries if possibleRyuta Kamizono2018-10-102-9/+8
| | | | | | | | | | | | | | Before: ``` Pet Destroy (0.8ms) DELETE FROM `pets` WHERE `pets`.`pet_id` IN (SELECT `pet_id` FROM (SELECT DISTINCT `pets`.`pet_id` FROM `pets` LEFT OUTER JOIN `toys` ON `toys`.`pet_id` = `pets`.`pet_id` WHERE `toys`.`name` = ?) AS __active_record_temp) [["name", "Bone"]] ``` After: ``` Pet Destroy (1.0ms) DELETE `pets` FROM `pets` LEFT OUTER JOIN `toys` ON `toys`.`pet_id` = `pets`.`pet_id` WHERE `toys`.`name` = ? [["name", "Bone"]] ```
* Simplify the condition in `prepare_update_statement`Ryuta Kamizono2018-10-051-8/+2
|
* Move UPDATE/DELETE with JOIN handling to the Arel sideRyuta Kamizono2018-10-032-37/+80
|
* Handle UPDATE/DELETE with OFFSET in ArelRyuta Kamizono2018-10-012-13/+18
|
* Handle DELETE with LIMIT in ArelRyuta Kamizono2018-09-302-26/+30
| | | | | | | | | | | | | | | | | | MySQL supports DELETE with LIMIT and ORDER BY. https://dev.mysql.com/doc/refman/8.0/en/delete.html Before: ``` Post Destroy (1.0ms) DELETE FROM `posts` WHERE `posts`.`id` IN (SELECT `id` FROM (SELECT `posts`.`id` FROM `posts` WHERE `posts`.`author_id` = ? ORDER BY `posts`.`id` ASC LIMIT ?) __active_record_temp) [["author_id", 1], ["LIMIT", 1]] ``` After: ``` Post Destroy (0.4ms) DELETE FROM `posts` WHERE `posts`.`author_id` = ? ORDER BY `posts`.`id` ASC LIMIT ? [["author_id", 1], ["LIMIT", 1]] ```
* `visitor.accept` doesn't handle `&block`Ryuta Kamizono2018-09-301-2/+2
|
* Remove `visit_Fixnum` and `visit_Bignum`Ryuta Kamizono2018-09-302-3/+0
| | | | Follow up ae406cd633dab2cafbc0d1bb5922d1ca40056ea0.
* Remove `visit_Fixnum` and `visit_Bignum`Ryuta Kamizono2018-09-281-2/+0
| | | | Since Ruby 2.4 unified Fixnum and Bignum into Integer.
* Make `update_counters` preparableRyuta Kamizono2018-09-281-1/+1
| | | | | | | | | | | | | | | | Before: ``` Topic Update All (0.4ms) UPDATE `topics` SET `topics`.`replies_count` = COALESCE(`topics`.`replies_count`, 0) + 1, `topics`.`updated_at` = '2018-09-27 18:34:05.068774' WHERE `topics`.`id` = ? [["id", 7]] ``` After: ``` Topic Update All (0.4ms) UPDATE `topics` SET `topics`.`replies_count` = COALESCE(`topics`.`replies_count`, 0) + ?, `topics`.`updated_at` = ? WHERE `topics`.`id` = ? [["replies_count", 1], ["updated_at", 2018-09-27 18:55:05 UTC], ["id", 7]] ```
* Make `update_all` preparableRyuta Kamizono2018-09-281-0/+4
| | | | | | | | | | | | | | Before: ``` Pet Update All (0.8ms) UPDATE `pets` LEFT OUTER JOIN `toys` ON `toys`.`pet_id` = `pets`.`pet_id` SET `pets`.`name` = 'Bob' WHERE `toys`.`name` = ? [["name", "Bone"]] ``` After: ``` Pet Update All (1.1ms) UPDATE `pets` LEFT OUTER JOIN `toys` ON `toys`.`pet_id` = `pets`.`pet_id` SET `pets`.`name` = ? WHERE `toys`.`name` = ? [["name", "Bob"], ["name", "Bone"]] ```
* Abandon TOP support.Vladimir Kochnev2018-09-254-16/+0
| | | | | | | | | | | | | | | | Initially, `TOP` was introduced to support `limit` for MSSQL database. Unlike PostgreSQL/MySQL/SQLite, MSSQL does not have native `LIMIT`/`OFFSET` support. The commit adding `TOP` is 1a246f71616cf246a75ef6cbdb56032e43d4e643. However, it figured out that `TOP` implementation was weak and it's not sufficient to also support `OFFSET`, then `TOP` was substituted with `ROW_NUMBER()` subquery in be48ed3071fd6524d0145c4ad3faeb4aafe3eda3. This is a well known trick in MSSQL - https://stackoverflow.com/questions/2135418/equivalent-of-limit-and-offset-for-sql-server. So now we don't need this `visit_Arel_Nodes_Top` at all. It does nothing useful but also adds an extra space after `SELECT` when `LIMIT` is being used for **any** database.
* Consistently use `visitor.compile`Ryuta Kamizono2018-09-091-2/+2
|
* Fix: Arel Postgresql visitor generates invalid SQL for GROUPING SETS.david2018-05-281-2/+2
|
* Arel: :nodoc: allMatthew Draper2018-02-2413-13/+13
|
* Arel: rubocop -aMatthew Draper2018-02-2413-1514/+1523
|
* Merge Arel into Active RecordMatthew Draper2018-02-2413-0/+2022