-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limit number of FileAnnotations retrieved for OMERO.web UI #519
Conversation
Refactors the stack which produces the list of existing FileAnnotations for selection in the "Choose attachments" dialog.
With a bunch of FileAnnotations created with https://github.com/will-moore/python-scripts/blob/main/create_file_annotations.py this looks like: If I add a bunch of FileAnnotations, then these are correctly excluded from the dialog next time I open it and the count goes down accordingly. Do we want to boost the page size and sort alphabetically as discussed? |
@will-moore I'm working on that today. |
I think this PR is failing tests at https://merge-ci.openmicroscopy.org/jenkins/job/OMERO-test-integration/lastCompletedBuild/testReport/OmeroWeb.test.integration.test_annotate/TestFileAnnotations/test_batch_add_fileannotations_2_/ The test is failing to exclude an annotation previously linked to the selected Projects. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the feature works, but I am being offered in the dialog attachments which I already attached. Basically concurring with @will-moore ' testing results
@will-moore @pwalczysko I added the |
<span>Select the attachments to add</span> | ||
<span> | ||
Select the attachments to add | ||
(total: {{ total_files }}{% if total_files > 500 %}, showing 500{% endif %}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor point: hard-coding 500
here and in container.py
feels a bit brittle.
I guess you could make a MAX_FILES
variable and add it into the context
, or add 'file_count': len(files)
to the page context and then do {% if total_files > file_count %}, showing {{ file_count }} {% endif %}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @will-moore, I wanted to do exactly that and then promptly forgot about it. Fixed now.
Works as expected on merge-ci. lgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes look good - tested locally (merge-ci unavailable just now, but had tested there earlier) - all working.
This pull request has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/unable-to-add-attachment-using-omero-web/84146/22 |
Addresses issue #517
The current "Choose attachment" dialog retrieves a list of every
FileAnnotation
not currently linked to the selected object(s) for linking, causing poor performance or failures on systems with a large number ofFileAnnotation
s.The goal of this PR is to address the potential performance impact only; any other improvements e.g. to the UI should be addressed in separate PRs.
Main discussion points:
API changes
getFilesByObject
now returns a tuple of the number of total files and a list ofFileAnnotationShim
s; previously the method returned a single list ofFileAnnotation
s.getFilesByObject
previously returned allFileAnnotation
s, and will now raise aValueError
. This also meanslistFileAnnotations
is no longer used and could be deprecated.Testing
There are currently no stated expectations to the exact behavior of the "Choose attachment" dialog or the
getFilesByObject
method. The UI also does not expose all of the available options of the method. With the large number of permutations of options and object types (and multiple object types, which are not handled), exhaustive testing will be difficult. Current testing is likely minimal.Potential pitfalls:
Discussion
FileAnnotation
s returned? Currently set to100
, but suggested to increase to several hundred.FileAnnotation
s be sorted? Currently by descendingupdateEvent.time
, but suggested to usename
as previously.