aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/relation.rb
Commit message (Collapse)AuthorAgeFilesLines
* Remove outdated "#TODO: Fix for binds." comment [ci skip]Ryuta Kamizono2016-09-111-1/+0
| | | | This comment was added at eaf5486 but already implemented.
* Ensure that inverse associations are set before running callbacksSean Griffin2016-08-311-4/+4
| | | | | | | | | | | | | | | | | If a parent association was accessed in an `after_find` or `after_initialize` callback, it would always end up loading the association, and then immediately overwriting the association we just loaded. If this occurred in a way that the parent's `current_scope` was set to eager load the child, this would result in an infinite loop and eventually overflow the stack. For records that are created with `.new`, we have a mechanism to perform an action before the callbacks are run. I've introduced the same code path for records created with `instantiate`, and updated all code which sets inverse instances on newly loaded associations to use this block instead. Fixes #26320.
* Switch back to `Hash.dup`Jon Moss2016-08-271-4/+2
| | | | | | | | | | | | | The performance difference between `Hash[]` and `Hash.dup` looks to have been narrowed by @tenderlove via this commit --> https://github.com/ruby/ruby/commit/b3803cc49ad382e23291d75ce57ffb2b74bb9577#diff-eff9999082c8ce7d8ba1fc1d79f439cf. Since this commit first appeared in Ruby 2.0.0, and since Rails now requires a minimum Ruby version of 2.2.2, this performance boost should be available for all users. Relevant links: - This behavior was originally added via https://github.com/rails/rails/commit/02174a3efc6fa8f2e5e6f114e4cf0d8a06305b6a - The conversation on the Ruby issue tracker lives here --> https://bugs.ruby-lang.org/issues/7166
* Remove over meta programming in AR::RelationBogdan Gusiev2016-08-231-9/+4
| | | | | | | | | | Introduced low level methods #set_value and #get_value for setting query attributes: relation.set_value(:where, {id: 1}) relation.get_value(:includes) Used those internally when working with relation's attributes at the abstract level
* code gardening: removes redundant selfsXavier Noria2016-08-081-1/+1
| | | | | | | | | A few have been left for aesthetic reasons, but have made a pass and removed most of them. Note that if the method `foo` returns an array, `foo << 1` is a regular push, nothing to do with assignments, so no self required.
* normalizes indentation and whitespace across the projectXavier Noria2016-08-061-34/+34
|
* applies new string literal convention in activerecord/libXavier Noria2016-08-061-6/+6
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Use `connection#to_sql` for construct an SQLRyuta Kamizono2016-07-191-10/+5
|
* Pass `pk: false` to `connection.insert` explicitly if do not have a primary keyRyuta Kamizono2016-07-011-1/+1
| | | | | | Because causing an extra query by `sql_for_insert` for guessing a primary key. https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/connection_adapters/postgresql/database_statements.rb#L121-L125
* Exists shouldn't error when used with `includes`Sean Griffin2016-05-301-6/+1
| | | | | | | | | | | | | | | | Currently `exists?` does some hackery where it assumes that we can join onto anything that we passed to `eager_load` or `includes`, which doesn't work if we are joining onto a polymorphic association. Actually figuring out if we want to include something would require knowledge deep within the join dependency module, which is hard to pull up. The simplest solution is just to pass a flag down that says we're not actually going to try to eager load any of the data. It's not the solution I'd like, but that code really needs to be untangled before we can do much with it. This is another attempt at 6d5b1fd which should address the concerns that led to reverting it in 4ecabed.
* Pass over all Rails 5 warnings, to make sure:Vipul A M2016-04-121-3/+3
| | | | | | | | | | - we are ending sentences properly - fixing of space issues - fixed continuity issues in some sentences. Reverts https://github.com/rails/rails/commit/8fc97d198ef31c1d7a4b9b849b96fc08a667fb02 . This change reverts making sure we add '.' at end of deprecation sentences. This is to keep sentences within Rails itself consistent and with a '.' at the end.
* Merge pull request #24247 from ypxing/refactor_substitute_valuesAndrew White2016-04-041-5/+5
|\ | | | | enhance ActiveRecord#substitute_values to loop values just once
| * enhance ActiveRecord#substitute_values to loop values just onceRick Xing2016-03-191-5/+5
| |
* | Move sequence value methods to Model levelArthur Neves2016-03-241-2/+2
|/ | | | | | | | | | | | | | | `prefetch_primary_key?` and `next_sequence_value` methods live in the connection level at the moment, that make sense when you are generating the sequence from the database, in the same connection. Which is the use case today at the Oracle and Postgres adapters. However if you have an service that generates IDs, that has nothing to do with the database connection, and should not be fetched from there. Another use case, is if you want to use another connection to fetch IDs, that would not be possible with the current implementation, however when we move those methods to the model level, you can use a new connection there. Also this makes easier for gems to add behavior on those methods.
* Mutating the result of Relation#to_a should not affect the relationMatthew Draper2016-02-211-14/+18
| | | | | | Clarifying this separation and enforcing relation immutability is the culmination of the previous efforts to remove the mutator method delegations.
* Extract a Relation#arel_attributeMatthew Draper2016-02-041-4/+8
|
* Defer Arel attribute lookup to the model classMatthew Draper2016-02-041-4/+4
| | | | | This still isn't as separated as I'd like, but it at least moves most of the burden of alias mapping in one place.
* `substitute_at` is no longer usedRyuta Kamizono2016-01-141-1/+1
| | | | Arel handles substitution for bind parameters by now.
* Fix user name in doc [ci skip]Ryuta Kamizono2015-12-311-1/+1
|
* `join_to_delete` is same as `join_to_update`Ryuta Kamizono2015-12-171-2/+2
| | | | Reapply #22615.
* Revert "Merge pull request #22615 from ↵Rafael Mendonça França2015-12-171-2/+2
| | | | | | | | | | kamipo/join_to_delete_is_same_as_join_to_update" This reverts commit 4d06ea9a829de8f6f5a345589828e182eacab6a3, reversing changes made to e9d15072a94e2ae4dec5b7a121c84a5db38547b8. Reason: This will break oracle-enhanced, see https://github.com/rsim/oracle-enhanced/blob/3c42131db82b64ac41645db3affc6e4650289df6/lib/active_record/connection_adapters/oracle_enhanced_adapter.rb#L1254
* `join_to_delete` is same as `join_to_update`Ryuta Kamizono2015-12-171-2/+2
|
* Revert "Perform a more efficient query in `Relation#any?`"Sean Griffin2015-12-141-1/+6
| | | | | | | | | This reverts commit 6d5b1fdf55611de2a1071c37544933bb588ae88e. `eager_load` and `references` can include hashes, which won't match up with `references` A test case has been added to demonstrate the problem
* Perform a more efficient query in `Relation#any?`Sean Griffin2015-12-141-6/+1
| | | | | | | | | | | This was changed in 421c81b, as `exists?` blows up if you are eager loading a polymorphic association, as it'll try to construct a join to that table. The previous change decided to execute a `count` instead, which wouldn't join. Of course, the only time we actually need to perform a join on the eager loaded values (which would perform a left outer join) is if they're being referenced in the where clause. This doesn't affect inner joins.
* Clean up and correct documentation for update_columns and update_all [ci skip]James Wen2015-12-051-3/+2
|
* Alias left_joins to left_outer_joinsTakashi Kokubun2015-10-311-1/+1
|
* Merge pull request #12071 from Crunch09/outer_joinsSean Griffin2015-10-301-1/+1
|\ | | | | | | added ActiveRecord::Relation#outer_joins
| * added ActiveRecord::Relation#left_outer_joinsFlorian Thomas2015-05-191-1/+1
| | | | | | | | | | | | Example: User.left_outer_joins(:posts) => SELECT "users".* FROM "users" LEFT OUTER JOIN "posts" ON "posts"."user_id" = "users"."id"
* | Add deprecation warning to `ActiveRecord::Relation#update`Ted Johansson2015-10-151-0/+7
| | | | | | | | | | | | | | | | When passing an instance of `ActiveRecord::Base` to `#update`, it would internally call `#find`, resulting in a misleading deprecation warning. This change gives this deprecated use of `#update` its own, meaningful warning.
* | applies new doc guidelines to Active Record.Yves Senn2015-10-141-31/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | [ci skip] Fix ActiveRecord::Relation#update documentationakihiro172015-10-051-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * before ``` people = Person.where(group: 'expert') people.update(group: 'masters') Note: Updating a large number of records will run a UPDATE query for each record, which may cause a performance issue. So if it is not needed to run callbacks for each update, it is preferred to use <tt>update_all</tt> for updating all records using a single query. ``` * after ``` people = Person.where(group: 'expert') people.update(group: 'masters') ``` Note: Updating a large number of records will run an UPDATE query for each record, which may cause a performance issue. So if it is not needed to run callbacks for each update, it is preferred to use <tt>update_all</tt> for updating all records using a single query.
* | File encoding is defaulted to utf-8 in Ruby >= 2.1Akira Matsuda2015-09-181-1/+0
| |
* | Deprecate passing conditions to AR::Relation destroy_all and delete_all methodsWojciech Wnętrzak2015-09-061-13/+10
| |
* | Add ActiveRecord::Relation#in_batchesSina Siadat2015-08-071-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `in_batches` yields Relation objects if a block is given, otherwise it returns an instance of `BatchEnumerator`. The existing `find_each` and `find_in_batches` methods work with batches of records. The new API allows working with relation batches as well. Examples: Person.in_batches.each_record(&:party_all_night!) Person.in_batches.update_all(awesome: true) Person.in_batches.delete_all Person.in_batches.map do |relation| relation.delete_all sleep 10 # Throttles the delete queries end
* | Add #cache_key to ActiveRecord::Relation.Alberto F. Capel2015-07-201-0/+26
| |
* | Include `Enumerable` in `ActiveRecord::Relation`Sean Griffin2015-06-191-20/+9
| | | | | | | | | | | | | | | | | | | | | | After discussing, we've decided it makes more sense to include it. We're already forwarding every conflicting method to `to_a`, and there's no conflation of concerns. `Enumerable` has no mutating methods, and it just allows us to simplify the code. No existing methods will have a change in behavior. Un-overridden Enumerable methods will simply delegate to `each`. [Sean Griffin & bogdan]
* | deprecate `Relation#uniq` use `Relation#distinct` instead.Yves Senn2015-05-261-1/+2
|/ | | | | | | | | See #9683 for the reasons we switched to `distinct`. Here is the discussion that triggered the actual deprecation #20198. `uniq`, `uniq!` and `uniq_value` are still around. They will be removed in the next minor release after Rails 5.
* Fix documentation for find_or_create_byJoe Van Dyk2015-03-211-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | The code in the comment fails on concurrent inserts if done inside a transaction. The fix is to force a savepoint to run so that if the database raises an unique violation exception. Otherwise, you'll get errors like: ``` (0.3ms) BEGIN Cart Load (0.5ms) SELECT "carts".* FROM "carts" WHERE "carts"."uuid" = '12345' LIMIT 1 # Another process inserts a cart with uuid of '12345' right now SQL (4371.7ms) INSERT INTO "carts" ("created_at", "updated_at", "uuid") VALUES ('2015-03-21 01:05:07.833231', '2015-03-21 01:05:07.833231', '12345') RETURNING "id" [["created_at", Sat, 21 Mar 2015 01:05:07 PDT -07:00], ["updated_at", Sat, 21 Mar 2015 01:05:07 PDT -07:00], ["uuid", "12345"]] PG::UniqueViolation: ERROR: duplicate key value violates unique constraint "carts_uuid_idx1" DETAIL: Key (uuid)=(12345) already exists. : INSERT INTO "carts" ("created_at", "updated_at", "uuid") VALUES ('2015-03-21 01:05:07.833231', '2015-03-21 01:05:07.833231', '12345') RETURNING "id" # Retrying the find Cart Load (0.8ms) SELECT "carts".* FROM "carts" WHERE "carts"."uuid" = '12345' LIMIT 1 PG::InFailedSqlTransaction: ERROR: current transaction is aborted, commands ignored until end of transaction block : SELECT "carts".* FROM "carts" WHERE "carts"."uuid" = '12345' LIMIT 1 (0.1ms) ROLLBACK ActiveRecord::StatementInvalid: PG::InFailedSqlTransaction: ERROR: current transaction is aborted, commands ignored until end of transaction block : SELECT "carts".* FROM "carts" WHERE "carts"."uuid" = '12345' LIMIT 1 ```
* Optimize none? and one? relation query methods to use LIMIT and COUNT.Eugene Gilburg2015-02-121-0/+18
| | | | | | | | Use SQL COUNT and LIMIT 1 queries for none? and one? methods if no block or limit is given, instead of loading the entire collection to memory. The any? and many? methods already follow this behavior. [Eugene Gilburg & Rafael Mendonça França]
* Remove Relation#bind_paramsSean Griffin2015-01-271-9/+9
| | | | | | | | `bound_attributes` is now used universally across the board, removing the need for the conversion layer. These changes are mostly mechanical, with the exception of the log subscriber. Additional, we had to implement `hash` on the attribute objects, so they could be used as a key for query caching.
* Unify access to bind values on RelationSean Griffin2015-01-271-6/+4
| | | | | | | | | | | | | | | | | | | The bind values can come from four places. `having`, `where`, `joins`, and `from` when selecting from a subquery that contains binds. These need to be kept in a specific order, since the clauses will always appear in that order. Up until recently, they were not. Additionally, `joins` actually did keep its bind values in a separate location (presumably because it's the only case that people noticed was broken). However, this meant that anything accessing just `bind_values` was broken (which most places were). This is no longer possible, there is only a single way to access the bind values, and it includes joins in the proper location. The setter was removed yesterday, so breaking `+=` cases is not possible. I'm still not happy that `joins` is putting it's bind values on the Arel AST, and I'm planning on refactoring it further, but this removes a ton of bug cases.
* Move the `from` bind logic to a `FromClause` classSean Griffin2015-01-261-3/+3
| | | | | | | Contrary to my previous commit message, it wasn't overkill, and led to much cleaner code. [Sean Griffin & anthonynavarre]
* Remove `Relation#bind_values=`Sean Griffin2015-01-261-1/+1
| | | | | | | | | | The last place that was assigning it was when `from` is called with a relation to use as a subquery. The implementation was actually completely broken, and would break if you called `from` more than once, or if you called it on a relation, which also had its own join clause, as the bind values would get completely scrambled. The simplest solution was to just move it into its own array, since creating a `FromClause` class for this would be overkill.
* Change `having_values` to use the `WhereClause` classSean Griffin2015-01-261-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | This fixed an issue where `having` can only be called after the last call to `where`, because it messes with the same `bind_values` array. With this change, the two can be called as many times as needed, in any order, and the final query will be correct. However, once something assigns `bind_values`, that stops. This is because we have to move all of the bind values from the having clause over to the where clause since we can't differentiate the two, and assignment was likely in the form of: `relation.bind_values += other.bind_values` This will go away once we remove all places that are assigning `bind_values`, which is next on the list. While this fixes a bug that was present in at least 4.2 (more likely present going back as far as 3.0, becoming more likely in 4.1 and later as we switched to prepared statements in more cases), I don't think this can be easily backported. The internal changes to `Relation` are non-trivial, anything that involves modifying the `bind_values` array would need to change, and I'm not confident that we have sufficient test coverage of all of those locations (when `having` was called with a hash that could generate bind values). [Sean Griffin & anthonynavarre]
* Move `where_values_hash` over to `WhereClause`Sean Griffin2015-01-251-16/+1
|
* Introduce `Relation::WhereClause`Sean Griffin2015-01-251-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way that bind values are currently stored on Relation is a mess. They can come from `having`, `where`, or `join`. I'm almost certain that `having` is actually broken, and calling `where` followed by `having` followed by `where` will completely scramble the binds. Joins don't actually add the bind parameters to the relation itself, but instead add it onto an accessor on the arel AST which is undocumented, and unused in Arel itself. This means that the bind values must always be accessed as `relation.arel.bind_values + relation.bind_values`. Anything that doesn't is likely broken (and tons of bugs have come up for exactly that reason) The result is that everything dealing with `Relation` instances has to know far too much about the internals. The binds are split, combined, and re-stored in non-obvious ways that makes it difficult to change anything about the internal representation of `bind_values`, and is extremely prone to bugs. So the goal is to move a lot of logic off of `Relation`, and into separate objects. This is not the same as what is currently done with `JoinDependency`, as `Relation` knows far too much about its internals, and vice versa. Instead these objects need to be black boxes that can have their implementations swapped easily. The end result will be two classes, `WhereClause` and `JoinClause` (`having` will just re-use `WhereClause`), and there will be a single method to access the bind values of a `Relation` which will be implemented as ``` join_clause.binds + where_clause.binds + having_clause.binds ``` This is the first step towards that refactoring, with the internal representation of where changed, and an intermediate representation of `where_values` and `bind_values` to let the refactoring take small steps. These will be removed shortly.
* Don't mutate bind values in `Relation`Sean Griffin2015-01-191-1/+0
| | | | | | | In order to better facilitate refactoring, most places that mutated `bind_values` have already been removed. One last spot snuck through. Since we're no longer mutating the array, it also does not need to be duped in `initialize_copy`.
* Stop passing a column to `quote` in `Relation#to_sql`Sean Griffin2015-01-101-2/+3
| | | | | | | I'm planning on deprecating the column argument to mirror the deprecation in [arel]. [arel]: https://github.com/rails/arel/commit/6160bfbda1d1781c3b08a33ec4955f170e95be11
* Merge pull request #11898 from prathamesh-sonpatki/patch-updateRafael Mendonça França2015-01-021-1/+13
|\ | | | | | | | | | | | | Changed ActiveRecord::Relation#update behavior so that it will work on Relation objects without giving id Conflicts: activerecord/CHANGELOG.md
| * Allow ActiveRecord::Relation#update to run on result of a relation with ↵Prathamesh Sonpatki2014-12-201-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | callbacks and validations - Right now, there is no method to update multiple records with validations and callbacks. - Changed the behavior of existing `update` method so that when `id` attribute is not given and the method is called on an `Relation` object, it will execute update for every record of the `Relation` and will run validations and callbacks for every record. - Added test case for validating that the callbacks run when `update` is called on a `Relation`. - Changed test_create_columns_not_equal_attributes test from persistence_test to include author_name column on topics table as it it used in before_update callback. - This change introduces performance issues when a large number of records are to be updated because it runs UPDATE query for every record of the result. The `update_all` method can be used in that case if callbacks are not required because it will only run single UPDATE for all the records.
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-29 12:54:38 +0000