Skip to content

Load project members, group members in bulk and cache it

Paco Guzman requested to merge 17932-move-to-project-dropdown-bulk-load into 17932-move-to-project-dropdown

What does this MR do?

On the Move dropdown on the edit issue page we introduced infinite scrolling to just return a limited number of projects, 50 items. So if the user can move the issue to 50 or more items when scroll down on the list a new set of projects will be requested to the server.

Are there points in the code the reviewer needs to double check?

As the list of projects is filtered with ruby from a first result set that is get using SQL, we tried to improve that filtering because execute a lot of queries (see screenshots of Sheerlock) preloading some data (to avoid those queries).

As we have infinite scrolling, when we receive and offset_id (which correspond with the last project id returned to that dropdown and stored on web browser), we skip the sql list of project until that point and start filtering from there (so we avoid all the queries for projects we're not going to return) and we filter projects until we reach the end of the list or we have a whole new page (50 items). We use a lazy enumerator to only filter what we need

Why was this MR needed?

See #17932 (closed)

What are the relevant issue numbers?

Closes #17932 (closed)

Screenshots (if relevant)

These are some tests I did on my local machine with an user with 27 authorized projects (19 belonging to a the same group). I cannot profile these on staging because there are a lot of changes related with the project_team class that are not yet on staging.

Current local master (59ce1af5) Screen_Shot_2016-08-09_at_09.43.32

Plain MR (!5686 (merged)) Screen_Shot_2016-08-09_at_09.46.08

This MR I'll push for review but the implementation is ugly Screen_Shot_2016-08-09_at_09.49.16

Does this MR meet the acceptance criteria?

Merge request reports