An error occurred fetching the project authors.
  1. 30 Sep, 2016 1 commit
  2. 27 Sep, 2016 1 commit
  3. 09 Aug, 2016 1 commit
  4. 12 Jul, 2016 1 commit
  5. 03 Jun, 2016 2 commits
  6. 16 May, 2016 2 commits
    • Sean McGivern's avatar
      Return a relation with Postgres · e8058bd2
      Sean McGivern authored
      Postgres only needs to select a single column, so that can used as a
      sub-query where `Milestone.upcoming_ids_by_projects` is actually used in
      `IssuableFinder`.
      
      MySQL needs to select the `due_date` column because it's used in the
      `HAVING` clause, so it has to return an array of IDs.
      e8058bd2
    • Sean McGivern's avatar
      Make upcoming milestone work across projects · 750b2ff0
      Sean McGivern authored
      Before: we took the next milestone due across all projects in the
      search and found issues whose milestone title matched that
      one. Problems:
      
      1. The milestone could be closed.
      2. Different projects have milestones with different schedules.
      3. Different projects have milestones with different titles.
      4. Different projects can have milestones with different schedules, but
         the _same_ title. That means we could show issues from a past
         milestone, or one that's far in the future.
      
      After: gather the ID of the next milestone on each project we're looking
      at, and find issues with those milestone IDs. Problems:
      
      1. For a lot of projects, this can return a lot of IDs.
      2. The SQL query has to be different between Postgres and MySQL, because
         MySQL is much more lenient with HAVING: as well as the columns
         appearing in GROUP BY or in aggregate clauses, MySQL allows them to
         appear in the SELECT list (un-aggregated).
      750b2ff0
  7. 09 May, 2016 1 commit
  8. 05 May, 2016 1 commit
  9. 17 Mar, 2016 1 commit
  10. 11 Mar, 2016 1 commit
  11. 07 Mar, 2016 1 commit
  12. 08 Feb, 2016 1 commit
  13. 09 Dec, 2015 1 commit
  14. 19 Oct, 2015 1 commit
    • Yorick Peterse's avatar
      Improve performance of sorting milestone issues · 4ff75e31
      Yorick Peterse authored
      This cuts down the time it takes to sort issues of a milestone by about
      10x. In the previous setup the code would run a SQL query for every
      issue that had to be sorted. The new setup instead runs a single SQL
      query to update all the given issues at once.
      
      The attached benchmark used to run at around 60 iterations per second,
      using the new setup this hovers around 600 iterations per second. Timing
      wise a request to update a milestone with 40-something issues would take
      about 760 ms, in the new setup this only takes about 130 ms.
      
      Fixes #3066
      4ff75e31
  15. 03 Oct, 2015 1 commit
  16. 22 Jun, 2015 1 commit
  17. 26 May, 2015 1 commit
    • Jonah Bishop's avatar
      Change percent_complete rescue value from 100 to 0 · 8b92946b
      Jonah Bishop authored
      The percent_complete method returns a value of 100 when a
      ZeroDivisionError occurs. That seems like a very strange default for an
      error case, and results in a bug when a milestone has no corresponding
      issues (new, empty milestones show 100% completion). This commit changes
      the rescue value to 0, and subsequently fixes #1656, which reported this
      problem.
      8b92946b
  18. 12 Feb, 2015 1 commit
  19. 26 Jun, 2014 1 commit
  20. 09 Apr, 2014 1 commit
  21. 21 Aug, 2013 2 commits
  22. 29 Jul, 2013 1 commit
  23. 11 Jun, 2013 1 commit
  24. 05 May, 2013 1 commit
  25. 15 Mar, 2013 1 commit
  26. 18 Feb, 2013 4 commits
  27. 03 Jan, 2013 2 commits
  28. 19 Nov, 2012 1 commit
  29. 13 Nov, 2012 1 commit
  30. 09 Oct, 2012 2 commits
  31. 26 Sep, 2012 1 commit
  32. 05 Sep, 2012 1 commit