aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/relation/calculations.rb
Commit message (Collapse)AuthorAgeFilesLines
* Use attribute_names over column_namesKeenan Brock2016-10-041-6/+2
|
* Merge pull request #26446 from kamipo/rename_type_var_name_to_typeEileen M. Uchitelle2016-09-171-10/+8
|\ | | | | Rename variable name that returning `type_for` to `type` from `column`
| * Rename variable name that returning `type_for` to `type` from `column`Ryuta Kamizono2016-09-111-10/+8
| | | | | | | | | | | | `column_for` was changed to `type_for` to return `type` object at 36bd52b4. But variable name is still `column`. It is very confusing. Rename variable name `column` to `type` for readability.
* | Fix broken comments indentation caused by rubocop auto-correct [ci skip]Ryuta Kamizono2016-09-141-7/+7
|/ | | | | | All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772. But comments was still kept absolute position. This commit aligns comments with method definitions for consistency.
* Add `Type.default_value` and use it everywhere for internalRyuta Kamizono2016-08-261-1/+1
| | | | For reduce instantiating `Type::Value`.
* Merge pull request #25976 from kamipo/pluck_uses_loaded_targetRafael França2016-08-171-1/+1
|\ | | | | `pluck` should use `records` (`load_target`) when `loaded?` is true
| * `pluck` should use `records` (`load_target`) when `loaded?` is trueRyuta Kamizono2016-08-041-1/+1
| |
* | Fix count which would sometimes force a DISTINCTMaxime Lapointe2016-08-161-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current behaviour of checking if there is a LEFT OUTER JOIN arel node to detect if we are doing eager_loading is wrong. This problem wasn't frequent before as only some pretty specific cases would add a LEFT OUTER JOIN arel node. However, the recent new feature left_outer_joins also add this node and made this problem happen frequently. Since in the perform_calculation function, we don't have access to eager_loading information, I had to extract the logic for the distinct out to the calculate method. As I was in the file for left_outer_join tests, I fixed a few that had bugs and I replaced some that were really weak with something that will catch more issues. In relation tests, the first test I changed would have failed if it had validated the hash returned by count instead of just checking how many pairs were in it. This is because this merge of join currently transforms the join node into an outer join node, which then made count do a distinct. So before this change, the return was {1=>1, 4=>1, 5=>1}.
* | applies remaining conventions across the projectXavier Noria2016-08-061-3/+3
| |
* | normalizes indentation and whitespace across the projectXavier Noria2016-08-061-148/+148
| |
* | applies new string literal convention in activerecord/libXavier Noria2016-08-061-14/+14
|/ | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Always prefer class types to query types when casting `group`Sean Griffin2016-07-111-4/+6
| | | | | | | | | | | | | When `group` is used in combination with any calculation method, the resulting hash uses the grouping expression as the key. Currently we're incorrectly always favoring the type reported by the query, instead of the type known by the class. This causes differing behavior depending on whether the adaptor actually gives proper types with the query or not. After this change, the behavior will be the same on all adaptors -- we see if we know the type from the class, fall back to the type from the query, and finally fall back to the identity type. Fixes #25595
* Support for unified Integer class in Ruby 2.4+Jeremy Daer2016-05-181-1/+1
| | | | | | | | Ruby 2.4 unifies Fixnum and Bignum into Integer: https://bugs.ruby-lang.org/issues/12005 * Forward compat with new unified Integer class in Ruby 2.4+. * Backward compat with separate Fixnum/Bignum in Ruby 2.2 & 2.3. * Drops needless Fixnum distinction in docs, preferring Integer.
* Forward ActiveRecord::Relation#count to Enumerable#count if block givenErik Michaels-Ober2016-03-191-1/+5
|
* Extract a Relation#arel_attributeMatthew Draper2016-02-041-1/+1
|
* Defer Arel attribute lookup to the model classMatthew Draper2016-02-041-10/+2
| | | | | 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.
* Refactor Calculations#execute_grouped_calculation and clean AR test caseRafael Sales2015-10-221-10/+4
| | | | | | | | | | | | | * When tried to use `Company#accounts` test/models/company.rb I got: ``` ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column: accounts.company_id: SELECT COUNT(*) AS count_all, "companies"."firm_id" AS companies_firm_id FROM "companies" INNER JOIN "accounts" ON "accounts"."company_id" = "companies"."id" GROUP BY "companies"."firm_id" ``` * The refactor on Calculations class was just to simplify the code
* Fix generated projection fields in group by queryRafael Sales2015-10-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Closes #21922 Let `Book(id, author_id)`, `Photo(id, book_id, author_id)` and `Author(id)` Running `Book.group(:author_id).joins(:photos).count` will produce: * Rails 4.2 - conflicts `author_id` in both projection and group by: ```sql SELECT COUNT(*) AS count_all, author_id AS author_id FROM "books" INNER JOIN "photos" ON "photos"."book_id" = "books"."id" GROUP BY author_id ``` * Master (9d02a25) - conflicts `author_id` only in projection: ```sql SELECT COUNT(*) AS count_all, author_id AS author_id FROM "books" INNER JOIN "photos" ON "photos"."book_id" = "books"."id" GROUP BY "books"."author_id" ``` * With this fix: ```sql SELECT COUNT(*) AS count_all, "books"."author_id" AS books_author_id FROM "books" INNER JOIN "photos" ON "photos"."book_id" = "books"."id" GROUP BY "books"."author_id" ```
* Merge pull request #20653 from repinel/allow-arel-select-countSean Griffin2015-10-201-1/+3
|\ | | | | Allow select using Arel and perform a count
| * Allow select with Arel and count as well as calculations with ArelRoque Pinel2015-06-301-1/+3
| | | | | | | | | | | | | | | | | | | | | | It allows a query like `User.select(:name).count` to be written using Arel as `User.select(User.arel_table[:name]).count`. It exposes the calculations API to accept Arel nodes: `User.count(User.arel_table[:name])`, `User.sum(User.arel_table[:id])`, `Account.average(Account.arel_table[:credit_limit])`, `Account.maximum(Account.arel_table[:credit_limit])` and `Account.minimum(Account.arel_table[:credit_limit])`.
* | Qualify column names in calculationSoutaro Matsumoto2015-10-201-1/+1
| | | | | | | | Column names inserted via `group` have to be qualified with table name.
* | applies new doc guidelines to Active Record.Yves Senn2015-10-141-15/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | docs, fix highlighting for code examples in calculations.rb [ci skip]Yves Senn2015-10-131-20/+20
| |
* | `column_alias_for` method is no more supporting *keys [ci skip]amitkumarsuroliya2015-09-261-1/+0
| |
* | remove warning from Calculations#sumyuuji.yaginuma2015-09-231-1/+1
| | | | | | | | | | | | | | This removes the following warning. ``` activerecord/lib/active_record/relation/calculations.rb:74: warning: `&' interpreted as argument prefix ```
* | Fix arguments of `AR::Calculations#sum`yui-knk2015-09-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Arguments of `#sum` does not match with other shortcuts methods (count, average, minimum, and maximum). This commit fix these two points: * call `super` with only block arguments First argument of `super` method, `Enumerable#sum`, is `identity` and first argument of `AR::Calculations#sum` is `column_name`. `Enumerable#sum` does not expect `column_name` to be passed. * Change first argument of `sum` from array arguemnt to single argument to match other shortcuts methods. When `sum` accept array arguemnt, user can pass multi arguments and an exception is raised from `calculate`.
* | [skip ci] #distinct instead of #uniqJon Atack2015-07-031-2/+3
|/ | | | | | | | as #uniq will be removed from Rails 5.0 as per the Active Support exception raised: ActiveSupport::DeprecationException: DEPRECATION WARNING: uniq is deprecated and will be removed from Rails 5.0 (use distinct instead).
* Update .pluck documentation on uniqPrem Sichanugrist2015-06-261-1/+1
| | | | | | This is to show users that they can chain `.uniq` and `.pluck` to get the `DISTINCT column` result. They don't have to do `DISTINCT column` themselves.
* Include `Enumerable` in `ActiveRecord::Relation`Sean Griffin2015-06-191-6/+3
| | | | | | | | | | | 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]
* Use `Enumerable#sum` on `ActiveRecord::Relation` when a block is givenSean Griffin2015-06-191-2/+6
| | | | | | | | This matches our behavior in other cases where useful enumerable methods might have a different definition in `Relation`. Wanting to actually enumerate over the records in this case is completely reasonable, and wanting `.sum` is reasonable for the same reason it is on `Enumerable` in the first place.
* Allow Enumerable#pluck to take a splat.Kevin Deisz2015-05-291-0/+4
| | | | | | This allows easier integration with ActiveRecord, such that AR#pluck will now use Enumerable#pluck if the relation is loaded, without needing to hit the database.
* Enhance documentation of pluck with a hint to ids [ci skip]wingfire2015-04-121-3/+5
| | | | | Documentation is giving an example that can be replaced by a more dry command. Give a hint that ids can be used instead of pluck(:id).
* Drop `references_eager_loaded_tables?` test from `has_include?`Ben Woosley2015-03-171-1/+1
| | | | | | | It is redundant with tests in `eager_loading?`, but for the difference between `includes_values.present?` and `includes_values.any?`, which is a difference without a distinction because `false` has no meaning for `includes`.
* Spell PostgreSQL correctly :elephant:Akira Matsuda2015-02-281-1/+1
| | | | [ci skip]
* `Type#type_cast_from_database` -> `Type#deserialize`Sean Griffin2015-02-171-2/+2
|
* Attribute assignment and type casting has nothing to do with columnsSean Griffin2015-01-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's finally finished!!!!!!! The reason the Attributes API was kept private in 4.2 was due to some publicly visible implementation details. It was previously implemented by overloading `columns` and `columns_hash`, to make them return column objects which were modified with the attribute information. This meant that those methods LIED! We didn't change the database schema. We changed the attribute information on the class. That is wrong! It should be the other way around, where schema loading just calls the attributes API for you. And now it does! Yes, this means that there is nothing that happens in automatic schema loading that you couldn't manually do yourself. (There's still some funky cases where we hit the connection adapter that I need to handle, before we can turn off automatic schema detection entirely.) There were a few weird test failures caused by this that had to be fixed. The main source came from the fact that the attribute methods are now defined in terms of `attribute_names`, which has a clause like `return [] unless table_exists?`. I don't *think* this is an issue, since the only place this caused failures were in a fake adapter which didn't override `table_exists?`. Additionally, there were a few cases where tests were failing because a migration was run, but the model was not reloaded. I'm not sure why these started failing from this change, I might need to clear an additional cache in `reload_schema_from_cache`. Again, since this is not normal usage, and it's expected that `reset_column_information` will be called after the table is modified, I don't think it's a problem. Still, test failures that were unrelated to the change are worrying, and I need to dig into them further. Finally, I spent a lot of time debugging issues with the mutex used in `define_attribute_methods`. I think we can just remove that method entirely, and define the attribute methods *manually* in the call to `define_attribute`, which would simplify the code *tremendously*. Ok. now to make this damn thing public, and work on moving it up to Active Model.
* Don't error when grouped calculations return 0 recordsSean Griffin2015-01-281-1/+1
| | | | Fixes #18717
* Remove Relation#bind_paramsSean Griffin2015-01-271-3/+3
| | | | | | | | `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-9/+3
| | | | | | | | | | | | | | | | | | | 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.
* Change `having_values` to use the `WhereClause` classSean Griffin2015-01-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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]
* Remove support to activerecord-deprecated_findersRafael Mendonça França2015-01-021-25/+12
|
* Fix ProtocolViolation/bind message supplies for polymorphic + pluck or groupMiklos Fazkeas2014-12-111-2/+2
|
* Correctly cast calculation results on PGSean Griffin2014-11-011-1/+2
| | | | | MySQL reports the column name as `"MAX(developer_id)"`. PG will report it as `"max"`
* Don't require calculations to be aliased to a columnSean Griffin2014-10-311-1/+1
| | | | | | | Arel has changed so that `.sum` no longer aliases `SUM(the_column)` to `sum_id`. This means the type returned by the adapter will be at the key `"SUM(the_column)"`. Longer term, we should eventually be able to retain type information from the AR::Base subclasses used in joined queries
* No need to call to_sym hereGodfrey Chan2014-09-201-7/+7
| | | | | The hash is now string-keyed, and [_]reflect_on_association calls `to_s` on the argument anyway.
* Fix typo in commentCade Truitt2014-07-021-1/+1
|
* Encapsulate knowledge of type objects on `ActiveRecord::Result`Sean Griffin2014-06-221-10/+1
| | | | | | | | | | | | | Attempting to reduce the number of places that care about the details of how type casting occurs. We remove the type casting of the primary key in `JoinDependecy`, rather than encapsulating it. It was originally added for consistency with https://github.com/rails/rails/commit/40898c8c19fa04442fc5f8fb5daf3a8bdb9a1e03#diff-06059df8d3dee3101718fb2c01151ad0R211, but that conditional was later removed in https://github.com/rails/rails/commit/d7ddaa530fd1b94e22d745cbaf2e8a5a34ee9734. What is important is that the same row twice will have the same value for the primary key, which it will.
* Don't use `Column` for type casting in Relation calculationsSean Griffin2014-06-181-12/+8
|
* [ci skip] add API doc for AR Group.Aditya Kapoor2014-06-171-1/+9
|
* Pluck should work with columns of the same name from different tablesSean Griffin2014-06-111-3/+1
| | | | | | | | The column name given by the adapter doesn't include the table namespace, so going through the hashed version of the result set causes overridden keys. Fixes #15649
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-02 19:09:03 +0000