aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/relation.rb
Commit message (Collapse)AuthorAgeFilesLines
* Remove deprecation of using ActiveRecord::Base instance in .updateRafael Mendonça França2017-01-031-2/+1
|
* Remove deprecated `#uniq`, `#uniq!`, and `#uniq_value`Ryuta Kamizono2016-12-301-9/+0
|
* Remove deprecated conditions parameter from #delete_allRafael Mendonça França2016-12-291-19/+11
|
* Remove deprecated conditions parameter from `#destroy_all`Rafael Mendonça França2016-12-291-10/+2
|
* fixing update_all and delete_all when chained with left_joins. fixes #27192Diego Plentz2016-11-271-2/+6
|
* docs, add `update_all` example with SQL fragment. [ci skip]Yves Senn2016-11-161-0/+3
| | | | | | The relation method `update_all` allows you to pass a SQL fragment. The functionality is already mentioned in the prose but the examples section does not cover it.
* Avoid `build_preloader` if preloading is not neededRyuta Kamizono2016-11-141-2/+3
|
* 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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-02 18:21:49 +0000