[KULRICE-9489] Determine best way to determine whether KRAD criteria fields treat wildcards and operators as literals Created: 14/May/13  Updated: 16/Jan/15

Status: Open
Project: Kuali Rice Development
Component/s: Development, JPA, Roadmap
Affects Version/s: None
Fix Version/s: 2.6
Security Level: Public (Public: Anyone can view)

Type: New Feature Priority: Critical
Reporter: Eric Westfall Assignee: Jonathan Keller
Resolution: Unresolved Votes: 0
Labels: Old
Remaining Estimate: 3 hours
Time Spent: Not Specified
Original Estimate: 3 hours

Rice Module:
KRAD Feature Area:
Persistence Framework
Sprint: 2.4.0-rc1 Sprint 7, 2.4.0-rc1 Sprint 8
KAI Review Status: Not Required
KTI Review Status: Not Required
Include in Release Notes?:


Legacy lookups invoked KNSServiceLocator.getBusinessObjectDictionaryService().isLookupFieldTreatWildcardsAndOperatorsAsLiteral(businessObjectClass, fieldName) when generating criteria queries. We need to determine the correct way to perform the equivalent in KRAD (in LookupCriteriaGeneratorQBC), given there is no analogous mapping in the DataDictionary. The KRAD LookupInputField contains the flag which specifies how the field interprets wildcards and operators. Criteria fields are defined on LookupViews, so the most straightforward strategy seems to be to iterate through those definitions to obtain the LookupInputFields. Since this is called in a loop over all criteria fields, we should make sure to return a map of the settings for all fields in the lookup view to avoid repeatedly iterating over them.


  • LookupCriteriaGeneratoreBase.getCollectionCriteriaFromMapUsingPrimaryKeysOnly
  • LookupCriteriaGeneratoreBase.doesLookupFieldTreatWildcardsAndOperatorsAsLiteral
  • LookupCriteriaGeneratorQBC.doesLookupFieldTreatWildcardsAndOperatorsAsLiteral

Comment by Eric Westfall [ 15/May/13 ]

Assigned to Jonathan. Jonathan this is the thing we talked about in the checkpoint the other day. Essentially, Aaron checked in a "naive" solution in the LookupCriteriaGeneratorQBC.doesLookupFieldTreatWildcardsAndOperatorsAsLiteral method. Note how in this method is going to fetch the view every single time it's called which will most certainly be inefficient.

Comment by Jonathan Keller [ 16/Sep/13 ]

So - we need to pass through a list of properties which should not be processed for wildcards to the lookup methods. This isn't information that the lookup service should be responsible for retrieving.

I would argue that the LookupService should be as independent of the view as possible, since there are use cases for calling these methods from non UI code.

Generated at Sat Jan 16 17:16:26 CST 2021 using JIRA 7.0.11#70121-sha1:19d24976997c1d95f06f3e327e087be0b71f28d4.