- 16 8月, 2016 2 次提交
-
-
由 Maxime Lapointe 提交于
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}.
-
由 Rafael Mendonça França 提交于
Style/SpaceBeforeBlockBraces Style/SpaceInsideBlockBraces Style/SpaceInsideHashLiteralBraces Fix all violations in the repository.
-
- 15 8月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
`find_nth` is protected method, therefore `offset` has not been passed anywhere. `find_nth_with_limit_and_offset` is unnecessary anymore because `offset` has not been passed.
-
- 14 8月, 2016 1 次提交
-
-
由 Michel Pigassou 提交于
When calling association.find RecordNotFound is now raised with the same argument as when we do it in Record.find (primary_key, id and model).
-
- 13 8月, 2016 1 次提交
-
-
由 Michael Grosser 提交于
-
- 11 8月, 2016 2 次提交
-
-
由 Ryuta Kamizono 提交于
Currently predicate builder cannot build a predicate for `array|range` attribute. This commit fixes the issue. Related #25671.
-
由 Ryuta Kamizono 提交于
Currently association queries cannot be preparable. ```ruby Post.where(author_id: 1).to_a # => SELECT "posts".* FROM "posts" WHERE "posts"."author_id" = ? [["author_id", 1]] Post.where(author: 1).to_a # => SELECT "posts".* FROM "posts" WHERE "posts"."author_id" = 1 ``` To make association queries to preparable, it should be handled in `create_binds_for_hash`. This change is a first step for it.
-
- 08 8月, 2016 2 次提交
-
-
由 Xavier Noria 提交于
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.
-
由 Xavier Noria 提交于
Some case expressions remain, need to think about those ones.
-
- 07 8月, 2016 6 次提交
-
-
由 Ryuta Kamizono 提交于
-
由 yui-knk 提交于
This method is not touched from outside.
-
由 Xavier Noria 提交于
-
由 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.
-
- 06 8月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
Passing arel node with splat binds for `where` was introduced at #22877 for uniqueness validator supports prepared statement. But I'd not like to introduce the following usage: ```ruby Foo.where(arel, *binds) ``` I'd like to revert this internal usage.
-
- 28 7月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 25 7月, 2016 1 次提交
-
-
由 Xavier Noria 提交于
-
- 24 7月, 2016 1 次提交
-
-
由 Xavier Noria 提交于
Where appropriatei, prefer the more concise Regexp#match?, String#include?, String#start_with?, or String#end_with?
-
- 14 7月, 2016 3 次提交
-
-
由 Xavier Noria 提交于
-
由 Xavier Noria 提交于
We are setting a limit unconditionally just below, which overrides any existing one anyway.
-
由 Xavier Noria 提交于
-
- 11 7月, 2016 1 次提交
-
-
由 Sean Griffin 提交于
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
-
- 02 7月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 16 6月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
`FinderMethods#exists?` should return a boolean rather than raising an exception. `UniquenessValidator#build_relation` catches a `RangeError` because it includes type casting due to a string value truncation. But a string value truncation was removed at #23523 then type casting in `build_relation` is no longer necessary. aa062318 removes type casting in `build_relation` then a `RangeError` moves to `relation.exists?`. This change will remove the catching a `RangeError`.
-
- 13 6月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
`construct_relation_for_association_calculations` pass a string value to `construct_join_dependency` when setting a string value in `from`. It should not pass a string value, but always `joins_values`. Related #14834, #19452. Fixes #24193.
-
- 11 6月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 31 5月, 2016 1 次提交
-
-
由 Sean Griffin 提交于
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 6d5b1fdf which should address the concerns that led to reverting it in 4ecabed2.
-
- 28 5月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 27 5月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
`association_for_table` is unused since 50a8cdf0.
-
- 19 5月, 2016 1 次提交
-
-
由 Jeremy Daer 提交于
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.
-
- 07 5月, 2016 1 次提交
-
-
由 Sean Griffin 提交于
In 5.0 we use bind parameters for limit and offset, while in 4.2 we used the values directly. The code as it was written assumed that limit and offset worked as `LIMIT ? OFFSET ?`. Both Oracle and SQL Server have a different syntax, where the offset is stated before the limit. We delegate this behavior to the connection adapter so that these adapters are able to determine how the bind parameters are flattened based on what order their specification has the various clauses appear. Fixes #24775
-
- 06 5月, 2016 1 次提交
-
-
由 Vipul A M 提交于
-
- 05 5月, 2016 1 次提交
-
-
由 yuuji.yaginuma 提交于
Passing conditions to `#destroy_all` was deprecated in c82c5f8f.
-
- 19 4月, 2016 1 次提交
-
-
由 Vipul A M 提交于
Don't create new arrays when trying to compute non_empty_predicates for where clause predicate. Get a 3-4% improvement in AST generation. Perf compare: https://gist.github.com/vipulnsward/7e4e9ecb157e574002313249a7969c82
-
- 13 4月, 2016 1 次提交
-
-
由 Sean Griffin 提交于
In 04ac5655 I assumed that we would never want to pass the "table_name.column_name" form to where with a symbol. However, in Ruby 2.2 and later, you can quote symbols using the new hash syntax, so it's a semi-reasonable thing to do if we want to support the dot notation (which I'd rather deprecate, but that would be too painful of a migration). Instead we've changed the definition of "this is a table name with a dot" to when the value associated is a hash. It would make very little sense to write `where("table_name.column_name": { foo: :bar })` in any scenario (other than equality for a JSON column which we don't support through `where` in this way). Close #24514.
-
- 12 4月, 2016 1 次提交
-
-
由 Vipul A M 提交于
- 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.
-
- 01 4月, 2016 1 次提交
-
-
由 Sean Griffin 提交于
This issue occured because associations now call `where` directly, and a dot in the key name for `where` means nested tables. For this fix, we now pass the table name as a symbol, and do not attempt to expand symbols containing a dot. This is a temporary fix. I do not think we should support table names containing a dot, as it has a special meaning in most backends, as well as most APIs that involve table names. This commit does not include a test, as I am going to deprecate table names containing dots in the following commit. Fixes #24367
-
- 31 3月, 2016 1 次提交
-
-
由 Gaurav Sharma 提交于
found these commits https://github.com/rails/rails/commit/9cc8c6f3730df3d94c81a55be9ee1b7b4ffd29f6, https://github.com/rails/rails/commit/9d79334a1dee67e31222c790e231772deafcaeb8 that also should remove it.
-
- 20 3月, 2016 1 次提交
-
-
由 Erik Michaels-Ober 提交于
-