flake8
passed.
JSHint
passed.
Add server-side filtering for repositories on "New Review Request"
Review Request #12140 — Created March 11, 2022 and submitted
The "New Review Request" page was designed for smaller servers in mind,
since in our heads, most people on large servers are (correctly) using
RBTools. To wit, it was loading the entirety of the repository list into
the sidebar of the page, and then providing client-side search of the
names. On servers with very large numbers of repositories, this would
cause major delays and even timeouts.This change fixes all that up to be much better. Rather than loading all
repositories, we load only the first 25. Instead of the special "File
attachments only" repository being something that is done in the view,
it happens entirely client-side. And the "Filter" search box will now
make queries to the API to regenerate the collection of repositories,
rather than just filtering the full collection on the client.This required adding a few new data fields to the repository API, as
well as the new "q" query parameter to the list API.
Created a bunch of different repositories on my local system. Typed some
stuff in the repository filter field and saw appropriate network
requests and that the repository collection was reloaded with the
returned results.
| Description | From | Last Updated |
|---|---|---|
|
Can you add a Version Added? |
 chipx86
|
|
|
This is just a suggestion and does not need to be done, but we could move this to the pattern … |
chipx86
|
|
|
I don't know that we're going to need to do any further 3.0.x releases, aside from the backport we know … |
chipx86
|
|
|
If we do __contains, we won't benefit from any indexes (and we've seen what that can do). Maybe just a … |
chipx86
|
|
|
Maybe cleaner as: queryset = queryset.filter(q).distinct() if 'q' in request.GET: queryset = queryset.order_by('name') return queryset |
chipx86
|
-
-
-
This is just a suggestion and does not need to be done, but we could move this to the pattern of building these attributes up-front in the Django view, then pass the result as
{{..|json_dumps}}here, simplifying this greatly. -
I don't know that we're going to need to do any further 3.0.x releases, aside from the backport we know of. Let's just target for 4.0.7. It'll be a little less confusing in the docs that way.
-
If we do
__contains, we won't benefit from any indexes (and we've seen what that can do). Maybe just a__startswith?I do like the idea of searching by path/mirror_path, but I also wonder if we can get by with just the name, given that.
-
Maybe cleaner as:
queryset = queryset.filter(q).distinct() if 'q' in request.GET: queryset = queryset.order_by('name') return queryset
- Commit:
-
59d7ddc3ad35a1457088bac9dcc1ebc1698c31385efd99288b74a51a5b879d5d00e1e4b6e501deae
- Diff:
-
Revision 2 (+147 -36)
Checks run (2 succeeded)
flake8
passed.
JSHint
passed.
- Change Summary:
-
Fix API docs
- Commit:
-
5efd99288b74a51a5b879d5d00e1e4b6e501deae95b4c815a62c9c8234e096988fb4da151606b88f
- Diff:
-
Revision 3 (+147 -36)
Checks run (2 succeeded)
flake8
passed.
JSHint
passed.