aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/arel/visitors
Commit message (Collapse)AuthorAgeFilesLines
* Address `ORA-01795: maximum number of expressions in a list is 1000`Yasuo Honda2019-04-112-0/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * To address this error, this commit splits expressions by slices of 1000 elements. * "Oracle Database Error Messages 18c" https://docs.oracle.com/en/database/oracle/oracle-database/18/errmg/ ``` ORA-01795: maximum number of expressions in a list is 1000 Cause: Number of expressions in the query exceeded than 1000. Note that unused column/expressions are also counted Maximum number of expressions that are allowed are 1000. ``` * This commit addresses this ORA-01795 error Note: Actually addressing this error raises another "ORA-00913: too many values" Number of values Oracle database allows is 65535 regardless bind values or literal values. ```ruby $ ARCONN=oracle bin/test test/cases/bind_parameter_test.rb -n test_too_many_binds ... snip ... Error: ActiveRecord::BindParameterTest#test_too_many_binds: ActiveRecord::StatementInvalid: OCIError: ORA-01795: maximum number of expressions in a list is 1000 stmt.c:267:in oci8lib_260.so /home/yahonda/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/ruby-oci8-2.2.7/lib/oci8/cursor.rb:131:in `exec' /home/yahonda/git/oracle-enhanced/lib/active_record/connection_adapters/oracle_enhanced/oci_connection.rb:142:in `exec' /home/yahonda/git/oracle-enhanced/lib/active_record/connection_adapters/oracle_enhanced/database_statements.rb:41:in `block in exec_query' /home/yahonda/git/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:676:in `block (2 levels) in log' /home/yahonda/.rbenv/versions/2.6.2/lib/ruby/2.6.0/monitor.rb:230:in `mon_synchronize' /home/yahonda/git/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:675:in `block in log' /home/yahonda/git/rails/activesupport/lib/active_support/notifications/instrumenter.rb:24:in `instrument' /home/yahonda/git/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:666:in `log' /home/yahonda/git/oracle-enhanced/lib/active_record/connection_adapters/oracle_enhanced/dbms_output.rb:36:in `log' /home/yahonda/git/oracle-enhanced/lib/active_record/connection_adapters/oracle_enhanced/database_statements.rb:24:in `exec_query' /home/yahonda/git/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:484:in `select' /home/yahonda/git/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:70:in `select_all' /home/yahonda/git/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:106:in `select_all' /home/yahonda/git/rails/activerecord/lib/active_record/relation/calculations.rb:299:in `block in execute_simple_calculation' /home/yahonda/git/rails/activerecord/lib/active_record/relation.rb:755:in `skip_query_cache_if_necessary' /home/yahonda/git/rails/activerecord/lib/active_record/relation/calculations.rb:299:in `execute_simple_calculation' /home/yahonda/git/rails/activerecord/lib/active_record/relation/calculations.rb:251:in `perform_calculation' /home/yahonda/git/rails/activerecord/lib/active_record/relation/calculations.rb:141:in `calculate' /home/yahonda/git/rails/activerecord/lib/active_record/relation/calculations.rb:49:in `count' /home/yahonda/git/rails/activerecord/test/cases/bind_parameter_test.rb:113:in `test_too_many_binds' bin/test test/cases/bind_parameter_test.rb:109 .............................F ```
* Revert unused code and re-using query annotation for `update_all` and ↵Ryuta Kamizono2019-04-011-4/+2
| | | | | | | | | | | | | | | | `delete_all` This partly reverts #35617. #35617 includes unused code (for `InsertStatement`) and re-using query annotation for `update_all` and `delete_all`, which has not been discussed yet. If a relation has any annotation, I think it is mostly for SELECT query, so re-using annotation by default is not always desired behavior for me. We should discuss about desired behavior before publishing the implementation.
* Add Relation#annotate for SQL commentingMatt Yoho2019-03-213-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch has two main portions: 1. Add SQL comment support to Arel via Arel::Nodes::Comment. 2. Implement a Relation#annotate method on top of that. == Adding SQL comment support Adds a new Arel::Nodes::Comment node that represents an optional SQL comment and teachers the relevant visitors how to handle it. Comment nodes may be added to the basic CRUD statement nodes and set through any of the four (Select|Insert|Update|Delete)Manager objects. For example: manager = Arel::UpdateManager.new manager.table table manager.comment("annotation") manager.to_sql # UPDATE "users" /* annotation */ This new node type will be used by ActiveRecord::Relation to enable query annotation via SQL comments. == Implementing the Relation#annotate method Implements `ActiveRecord::Relation#annotate`, which accepts a comment string that will be appeneded to any queries generated by the relation. Some examples: relation = Post.where(id: 123).annotate("metadata string") relation.first # SELECT "posts".* FROM "posts" WHERE "posts"."id" = 123 # LIMIT 1 /* metadata string */ class Tag < ActiveRecord::Base scope :foo_annotated, -> { annotate("foo") } end Tag.foo_annotated.annotate("bar").first # SELECT "tags".* FROM "tags" LIMIT 1 /* foo */ /* bar */ Also wires up the plumbing so this works with `#update_all` and `#delete_all` as well. This feature is useful for instrumentation and general analysis of queries generated at runtime.
* Merge pull request #35664 from jeremyevans/remove-roflscalingRafael França2019-03-193-85/+26
|\ | | | | Remove roflscaling
| * Remove roflscaling constantsJeremy Evans2019-03-192-15/+0
| |
| * Remove roflscalingJeremy Evans2019-03-183-70/+26
| | | | | | | | | | | | | | | | | | | | | | roflscaling (using frozen string constants instead of literal strings) was added in 2012, before frozen string literals were added in Ruby 2.3. Now that Rails no longer supports Ruby <2.3, and all of these files use frozen string literals, there is no reason to keep the roflscaling. This does not delete or deprecate the related constants. Such a change can be made in a later commit.
* | Extract `sanitize_as_sql_comment` from SQL visitor into connectionRyuta Kamizono2019-03-194-8/+11
|/ | | | Probably that is useful for any other feature as well.
* Merge pull request #35653 from kamipo/remove_arel_nodes_valuesRyuta Kamizono2019-03-183-23/+4
|\ | | | | Get rid of `Arel::Nodes::Values`
| * Get rid of `Arel::Nodes::Values`Ryuta Kamizono2019-03-183-23/+4
| | | | | | | | | | | | That is completely covered by `Arel::Nodes::ValuesList`. Related https://github.com/rails/arel/pull/484.
* | Add test case to prevent possible SQL injectionRyuta Kamizono2019-03-181-1/+3
|/
* Support Optimizer HintsRyuta Kamizono2019-03-166-0/+45
| | | | | | | | | | | | | | | | | | We as Arm Treasure Data are using Optimizer Hints with a monkey patch (https://gist.github.com/kamipo/4c8539f0ce4acf85075cf5a6b0d9712e), especially in order to use `MAX_EXECUTION_TIME` (refer #31129). Example: ```ruby class Job < ApplicationRecord default_scope { optimizer_hints("MAX_EXECUTION_TIME(50000) NO_INDEX_MERGE(jobs)") } end ``` Optimizer Hints is supported not only for MySQL but also for most databases (PostgreSQL on RDS, Oracle, SQL Server, etc), it is really helpful to turn heavy queries for large scale applications.
* 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
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-07 22:24:42 +0000