ConceptService#getConceptsByClass(…) uses Lucene under the hood! I think the reason for this was to achieve reusability of this complex method that leverages Lucene. However this gets superfluous to take such a long route when we have a ConceptClass at hand. For some reasons that I’m not certain of, relying on Lucene slows down the retrieval of data in this context! This becomes so critical if the API is consumed by an HFE tag that is processed multiple times by the <repeat/> tag!
Our Experience with the <condition/> HFE tag
The <condition/> tag somewhere relies on this API… We have an HFE form that consumes this tag. However, we may want to record upto 10 conditions in an encounter, so this tag is replicated 10 times by the <repeat/> tag; meaning this API would be hit 10 times causing a significantly slowed down yield of results! On my dev machine, it takes upto 2 minutes to load such a form; a machine with lower specs might just timeout!
@mksd it looks to me from the code you linked to that this is only an issue if it is not configured as “autocomplete”. If you use style=“autocomplete” does it still load every Concept by class each time it hits the tag, or is the autocomplete more of a dynamic search?
Yeah @mksd, the ObsSubmissionElement is a beast to follow, but in the autocomplete use case that method is never hit, but instead it renders a DynamicAutocompleteWidget does a more targeted search.
The right thing to do, I think, would be to just fix the getConceptsByClass(ConceptClass) method… there’s really no reason to do a Lucene lookup here, right? There is no free-text searching we are doing here, correct? (it’s taking a ConceptClass, not a String). Unless I’m nissing something, this seems like a backportable fix…