Stream StudyCachables in QueryHelper

[labkey-adam]

Rationale

QueryHelper() retrieved objects from the database via a cached stream (backed by a list), copied those objects into another list, and then enumerated the second list to create the map that it actually caches. This meant it (temporarily) held three in-memory copies of the collection at initialization time. Large studies (e.g., many study visits) also produced a warning at retrieval time. This switches to retrieving the objects via an uncached stream, and passing that stream through to the map-creation code path, eliminating the warning and two collection copies. It's still caching a (potentially large) map, but that's an acceptable trade-off for commonly used objects.

[labkey-jeckels]

Very minor suggestions

[labkey-jeckels]

Suggested change

	private DatasetCollections(Map<Integer, DatasetDefinition> stream)
	private DatasetCollections(Map<Integer, DatasetDefinition> map)

[labkey-jeckels]

Suggested change

	super(stream);
	super(map);

[labkey-jeckels]

Marginal benefit from closing the stream/ResultSet prior to creating the collections.

Suggested change

	try (Stream<T> stream = getTableSelector(key).uncachedStream(_objectClass))
	{
	return createCollections(Collections.unmodifiableMap(stream
	.peek(StudyCachable::lock)
	.toList()
	));
	.collect(LabKeyCollectors.toLinkedMap(StudyCachable::getPrimaryKey, v -> v))
	));
	}
	Map<K, T> map;
	try (Stream<T> stream = getTableSelector(key).uncachedStream(_objectClass))
	{
	map = stream.peek(StudyCachable::lock)
	.collect(LabKeyCollectors.toLinkedMap(StudyCachable::getPrimaryKey, v -> v))
	));
	}
	return createCollections(Collections.unmodifiableMap(map));

[labkey-adam]

Yeah, that's exactly what I intended, but not what my fingers typed. Should be fixed up now.