Skip to content

Conversation

@labkey-nicka
Copy link
Contributor

@labkey-nicka labkey-nicka commented Nov 15, 2024

Rationale

When attempting to resolve a TableInfo from a Domain for the AssayDomainKind we currently iterate over all the assay definitions in a container and for each provider we call provider.createProtocolSchema() and then hydrate full TableInfo instances until we find a match.

This refactors the approach to first resolve the singularly desired provider and only induce the provider.createProtocolSchema() call for that provider to then resolve the TableInfo.

Related Pull Requests

Changes

  • Refactor away AssayManager.getTableInfoForDomainId() by directly resolving the assay protocol/provider in AssayDomainKind.getTableInfo() and then instantiating a new schema for only that assay.
  • Separate AbstractAssayProvider.getDomains() into getDomains() and getDomainsAndDefaultValues() to make getDomains() more clear in its role and what it will return (i.e. a List<Domain> rather than a List<Pair<Domain, Map<DomainProperty, Object>>>)
  • Update assay-assayList.api matching on protocol "name" and provider "type" to be case-insensitive.
  • Add null checks

@labkey-nicka labkey-nicka merged commit 0a989c8 into develop Nov 15, 2024
2 checks passed
@labkey-nicka labkey-nicka deleted the fb_faster_assay branch November 15, 2024 23:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants