Issue 53997: Establish a maximum size for query selections

[labkey-nicka]

Rationale

This addresses Issue 53997 by establishing a maximum query selection size of (M=100,000). Some things to note:

API Changes

1. The query-selectAll.api will now select up to the first M rows. If the underlying query contains more rows than the maximum, then the first M will be selected. If the underlying query contains less than M rows, then all rows will be selected.
2. The query-setSelection.api (named QueryController.SetCheckAction) will reject any selection that will result in a selection size over the maximum. When rejected the pre-existing selection will remain unchanged.

UI Changes

1. In the event that an application grid or a LKS data region is displaying a grid with more than M rows, then the "Select All" button will instead display "Select First M Rows".
2. If a user manually selects more than the maximum amount, then an error will be displayed inline in either the application grid or LKS data region.

Related Pull Requests

• Issue 53997: Establish a maximum size for query selections labkey-ui-components#1865
• Issue 53997: Establish a maximum size for query selections #7107
• https://github.com/LabKey/limsModules/pull/1713
• Issue 53997: Establish a maximum size for query selections testAutomation#2738

Changes

• Refactor selections to consistently make use of LinkedHashSet making comparison/iteration operations much faster. Formerly, we were converting between different structures which resulted in a lot more time composing/iterating (e.g., clearing a selection where the selection size is very large).
• Update client-side data region to render Select First M Rows button when applicable.
• Display error message in data region if selection is greater than M.
• Declare constant maximum selection size on server. Pass to client via module context property.

[labkey-jeckels]

Maybe I'm misreading the code or expected behavior, but it seems like this won't be true if there are any existing rows selected that aren't in the first M rows:

The query-selectAll.api will now select up to the first M rows

I think createSelectionSet() will return 100,000 entries, which will then be rejected when merged with the existing selection in setSelected().

Maybe that's fine, but it's a more muddled of a behavior to describe.

[XingY]

LinkedHashSet uses significantly more memory than ArrayList.

[labkey-nicka]

Understood but the ArrayList here was just interstitial. Mainly looking to go from a String[] to a LinkedHashSet as quickly as possible.

[labkey-nicka]

In general, the change here to stop converting to lists is significantly more performant since we end up doing set logic on these and conversions between the same types is much faster. Saw a significant reduction in processing time switching everything to using the same set structure (e.g., "Clear all" selection).