- 16 8月, 2016 2 次提交
-
-
由 Ryuta Kamizono 提交于
If handled as an associated predicate even though a table has the column, will generate invalid SQL by valid column name treated as a table name.
-
由 Rafael Mendonça França 提交于
Style/SpaceBeforeBlockBraces Style/SpaceInsideBlockBraces Style/SpaceInsideHashLiteralBraces Fix all violations in the repository.
-
- 11 8月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 07 8月, 2016 4 次提交
-
-
由 Ryuta Kamizono 提交于
-
由 Xavier Noria 提交于
-
由 Xavier Noria 提交于
-
由 Xavier Noria 提交于
The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
-
- 17 7月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 11 4月, 2016 1 次提交
-
-
由 Prathamesh Sonpatki 提交于
- The negative scenario test case was missing earlier.
-
- 17 2月, 2016 2 次提交
-
-
由 Prathamesh Sonpatki 提交于
- Previously it used to show error message <"undefined method `limit_value' for {:title=>\"Rails\"}:Hash"> - Now it shows following error message. >> Post.where.not(name: 'DHH').or(name: 'Tenderlove') ArgumentError: You have passed Hash object to #or. Pass an ActiveRecord::Relation object instead. - Fixes #23714.
-
由 Philippe Huibonhoa 提交于
When passing in an array of different types of objects to `where`, it would only take into account the class of the first object in the array. PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)]) # => SELECT "price_estimates".* FROM "price_estimates" WHERE ("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" IN (1, 2)) This is fixed to properly look for any records matching both type and id: PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)]) # => SELECT "price_estimates".* FROM "price_estimates" WHERE (("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" = 1) OR ("price_estimates"."estimate_of_type" = 'Car' AND "price_estimates"."estimate_of_id" = 2))
-
- 04 2月, 2016 2 次提交
-
-
由 Akira Matsuda 提交于
-
由 Matthew Draper 提交于
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.
-
- 15 1月, 2016 1 次提交
-
-
由 Sean Griffin 提交于
The code that set the from clause was removed in bdc51416. I did not give any reason for doing so. My assumption was that I intended to change it to use the clause objects, but forgot. We appeared to not have test coverage for this case. Fixes #22996
-
- 13 1月, 2016 3 次提交
-
-
由 Rafael Mendonça França 提交于
When you are using scopes and you chaining these scopes it is hard to know which are the values that are incompatible. This way you can read the message and know for which values you need to look for. [Herminio Torres]
-
由 Sean Griffin 提交于
This reverts commit 5d41cb3b. This implementation does not properly handle cases involving predicates which are not associated with a bind param. I have the fix in mind, but don't have time to implement just yet. It will be more similar to #22823 than not.
-
由 Sean Griffin 提交于
While the predicates are an arel equality node where the left side is a full arel attribute, the binds just have the name of the column and nothing else. This means that while splitting the predicates can include the table as a factor, the binds cannot. It's entirely possible that we might be able to have the bind params carry a bit more information (I don't believe the name is used for anything but logging), and that is probably a worthwhile change to make in the future. However the simplest (and likely slightly faster) solution is to simply use the indices of the conflicts in both cases. This means that we only have to compute the collision space once, instead of twice even though we're doing an additional array iteration. Regardless, this method isn't a performance hotspot. Close #22823. [Ben Woosley & Sean Griffin]
-
- 02 12月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
It appears that I missed this one when I delegated all the non-mutation array methods that were not on Enumerable
-
- 24 11月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
As was pointed out by #17128, our blacklist of mutation methods was non-exhaustive (and would need to be kept up to date with each new version of Ruby). Now that `Relation` includes `Enumerable`, the number of methods that we actually need to delegate are pretty small. As such, we can change to explicitly delegating the few non-mutation related methods that `Array` has which aren't on `Enumerable`
-
- 02 11月, 2015 1 次提交
-
- 31 10月, 2015 1 次提交
-
-
由 Takashi Kokubun 提交于
-
- 17 10月, 2015 1 次提交
-
-
由 yui-knk 提交于
-
- 16 10月, 2015 1 次提交
-
-
由 Jake Worth 提交于
[#20473]
-
- 02 10月, 2015 1 次提交
-
-
由 Guo Xiang Tan 提交于
-
- 17 9月, 2015 1 次提交
-
-
由 Ronak Jangir 提交于
-
- 28 5月, 2015 1 次提交
-
-
由 Rafael Mendonça França 提交于
-
- 26 5月, 2015 2 次提交
-
-
由 Arun Agrawal 提交于
Was left in adfab2dc
-
由 Yves Senn 提交于
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.
-
- 26 3月, 2015 1 次提交
-
-
由 Jason Nochlin 提交于
When set to an integer, a warning will be logged whenever a result set larger than the specified size is returned by a query. Fixes #16463 The warning is outputed a module which is prepended in an initializer, so there will be no performance impact if `config.active_record.warn_on_records_fetched_greater_than` is not set.
-
- 04 2月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
While we query the proper columns, we go through normal handling for converting the value to a primitive which assumes it should use the table's primary key. If the association specifies a different value (and we know that we're working with an association), we should use the custom primary key instead. Fixes #18813.
-
- 30 1月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
-
- 29 1月, 2015 2 次提交
-
-
由 Sean Griffin 提交于
-
由 Matthew Draper 提交于
Post.where('id = 1').or(Post.where('id = 2')) # => SELECT * FROM posts WHERE (id = 1) OR (id = 2) [Matthew Draper & Gael Muller]
-
- 28 1月, 2015 4 次提交
-
-
由 Sean Griffin 提交于
`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.
-
由 Sean Griffin 提交于
The column is primarily used for type casting, which we're trying to separate from the idea of a column. Since what we really need is the combination of a name, type, and value, let's use the object that we already have to represent that concept, rather than this tuple. No consumers of the bind values have been changed, only the producers (outside of tests which care too much about internals). This is *finally* possible since the bind values are now produced from a reasonable number of lcoations.
-
由 Sean Griffin 提交于
The only place it was accessed was in tests. Many of them have another way that they can test their behavior, that doesn't involve reaching into internals as far as they did. `AssociationScopeTest` is testing a situation where the where clause would have one bind param per predicate, so it can just ignore the predicates entirely. The where chain test was primarly duplicating the logic tested on `WhereClause` directly, so I instead just make sure it calls the appropriate method which is fully tested in isolation.
-
由 Sean Griffin 提交于
-
- 27 1月, 2015 2 次提交
-
-
由 Sean Griffin 提交于
Contrary to my previous commit message, it wasn't overkill, and led to much cleaner code. [Sean Griffin & anthonynavarre]
-
由 Sean Griffin 提交于
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.
-
- 26 1月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
-