fbcf3bd3fc
This class now uses a UNION (when needed) instead of plucking tens of thousands of project IDs into memory. The tests have also been re-written to ensure all different use cases are tested properly (assuming I didn't forget any cases). The finder has also been broken up into 3 different finder classes: * ContributedProjectsFinder: class for getting the projects a user contributed to. * PersonalProjectsFinder: class for getting the personal projects of a user. * ProjectsFinder: class for getting generic projects visible to a given user. Previously a lot of the logic of these finders was handled directly in the users controller. |
||
---|---|---|
.. | ||
contributed_projects_finder.rb | ||
groups_finder.rb | ||
issuable_finder.rb | ||
issues_finder.rb | ||
joined_groups_finder.rb | ||
merge_requests_finder.rb | ||
milestones_finder.rb | ||
notes_finder.rb | ||
personal_projects_finder.rb | ||
projects_finder.rb | ||
README.md | ||
snippets_finder.rb | ||
trending_projects_finder.rb |
Finders
This type of classes responsible for collection items based on different conditions. To prevent lookup methods in models like this:
class Project
def issues_for_user_filtered_by(user, filter)
# A lot of logic not related to project model itself
end
end
issues = project.issues_for_user_filtered_by(user, params)
Better use this:
issues = IssuesFinder.new(project, user, filter).execute
It will help keep models thiner.