1. 20 7月, 2017 1 次提交
  2. 18 7月, 2017 1 次提交
    • R
      Fix `JoinDependency` with using a custom table · ea09bf54
      Ryuta Kamizono 提交于
      Without this fix, `JoinDependency` doesn't use a custom table alias:
      
      ```
      % ARCONN=sqlite3 be ruby -w -Itest test/cases/relations_test.rb -n test_using_a_custom_table_with_joins_affects_the_wheres
      Using sqlite3
      Run options: -n test_using_a_custom_table_with_joins_affects_the_wheres --seed 14531
      
      E
      
      Error:RelationTest#test_using_a_custom_table_with_joins_affects_the_wheres:
      ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column: posts.author_id: SELECT  "omg_posts".* FROM "posts" "omg_posts" INNER JOIN "authors" ON "authors"."id" = "posts"."author_id" WHERE "omg_posts"."title" = ? LIMIT ?
      ```
      ea09bf54
  3. 17 7月, 2017 1 次提交
  4. 06 7月, 2017 1 次提交
    • E
      Skip query cache for in_batches and friends · 6658e374
      Eugene Kenny 提交于
      The `find_each`, `find_in_batches` and `in_batches` APIs usually operate
      on large numbers of records, where it's preferable not to load them all
      into memory at once.
      
      If the query cache is enabled, it will hold onto the query results until
      the end of the execution context (request/job), which means the memory
      used is still proportional to the total number of records. These queries
      are typically not repeated, so the query cache isn't desirable here.
      6658e374
  5. 02 7月, 2017 1 次提交
  6. 01 7月, 2017 1 次提交
  7. 29 6月, 2017 1 次提交
  8. 24 6月, 2017 1 次提交
  9. 20 6月, 2017 1 次提交
  10. 15 6月, 2017 2 次提交
  11. 11 5月, 2017 1 次提交
  12. 10 4月, 2017 1 次提交
  13. 09 4月, 2017 1 次提交
  14. 04 4月, 2017 1 次提交
  15. 29 3月, 2017 1 次提交
    • W
      FinderMethods#fourty_two docs cite proper source · e77d4d1e
      Winfred Nadeau 提交于
      silly method gets a silly doc fix, 
      or I'm missing an even sillier joke and I'm about to get schooled.
      
      BUT I'm pretty sure this is some serious Beaudrillard simulacrum, though.
      I'm just doing my part to spread the gospel of Douglas Adams.
      e77d4d1e
  16. 26 2月, 2017 2 次提交
  17. 31 1月, 2017 1 次提交
  18. 04 1月, 2017 1 次提交
  19. 30 12月, 2016 1 次提交
  20. 29 12月, 2016 1 次提交
  21. 24 12月, 2016 1 次提交
  22. 06 12月, 2016 1 次提交
  23. 24 11月, 2016 1 次提交
    • D
      Restore RecordNotFound when *_ids= can't find records by ID · 15e2da65
      Dominic Cleal 提交于
      9c9fb19b changed the behaviour of the _ids= setters for associations to
      raise an AssociationTypeMismatch when unknown IDs are given:
      
          Class: <ActiveRecord::AssociationTypeMismatch>
          Message: <"Developer(#43811860) expected, got NilClass(#16732720)">
      
      This restores the original ActiveRecord::RecordNotFound exception with a
      much clearer error message:
      
          Class: <ActiveRecord::RecordNotFound>
          Message: <"Couldn't find all Developers with 'id': (1, -9999) [WHERE \"contracts\".\"company_id\" = ?] (found 1 results, but was looking for 2)">
      
      Fixes #25719
      15e2da65
  24. 09 11月, 2016 1 次提交
    • R
      Should except `:distinct` rather than `:order` for `exists?` · 2bf7c300
      Ryuta Kamizono 提交于
      Records fetching order is very important for performance if `limit` is
      presented. Should not except the order in the case.
      
      And `exists?` replaces select list to `1 AS one` therefore `:distinct`
      is useless (`DISTINCT 1 AS one`). And PostgreSQL raises the following
      error if `:distinct` and `:order` are used in the same time.
      
      ```
      ERROR:  for SELECT DISTINCT, ORDER BY expressions must appear in select list
      ```
      2bf7c300
  25. 23 9月, 2016 1 次提交
  26. 03 9月, 2016 1 次提交
  27. 18 8月, 2016 1 次提交
  28. 16 8月, 2016 2 次提交
  29. 15 8月, 2016 1 次提交
  30. 14 8月, 2016 1 次提交
  31. 08 8月, 2016 1 次提交
  32. 07 8月, 2016 2 次提交
  33. 28 7月, 2016 1 次提交
  34. 16 6月, 2016 1 次提交
    • R
      Prevent `RangeError` for `FinderMethods#exists?` · 1cf467b7
      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`.
      1cf467b7
  35. 13 6月, 2016 1 次提交
  36. 31 5月, 2016 1 次提交
    • S
      Exists shouldn't error when used with `includes` · 02da8aea
      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.
      02da8aea