Details
-
Type:
New Feature
-
Status: Open
-
Priority:
Critical
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: 2.6
-
Component/s: Development, JPA, Roadmap
-
Security Level: Public (Public: Anyone can view)
-
Labels:
-
Rice Module:KNS, KRAD
-
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?:Yes
Description
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.
See
- LookupCriteriaGeneratoreBase.getCollectionCriteriaFromMapUsingPrimaryKeysOnly
- LookupCriteriaGeneratoreBase.doesLookupFieldTreatWildcardsAndOperatorsAsLiteral
- LookupCriteriaGeneratorQBC.doesLookupFieldTreatWildcardsAndOperatorsAsLiteral
Attachments
Activity
| Field | Original Value | New Value |
|---|---|---|
| Link |
This issue cloned to |
| Link |
This issue cloned to |
| Description | LookupDao implementations are parsing lookup expressions and constructing and executing native OJB and JPQL queries. This logic needs to be converted such that the resultant query can be executed by the DataObjectService/PersistenceProvider {{findMatching}} methods which take the portable {{QueryByCriteria}} query/criteria abstraction. | 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. |
| Description | 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. |
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.
See {{LookupCriteriaGeneratoreBase.getCollectionCriteriaFromMapUsingPrimaryKeysOnly}}, {{LookupCriteriaGeneratoreBase.doesLookupFieldTreatWildcardsAndOperatorsAsLiteral}}, {{LookupCriteriaGeneratorQBC.doesLookupFieldTreatWildcardsAndOperatorsAsLiteral}} |
| Description |
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.
See {{LookupCriteriaGeneratoreBase.getCollectionCriteriaFromMapUsingPrimaryKeysOnly}}, {{LookupCriteriaGeneratoreBase.doesLookupFieldTreatWildcardsAndOperatorsAsLiteral}}, {{LookupCriteriaGeneratorQBC.doesLookupFieldTreatWildcardsAndOperatorsAsLiteral}} |
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.
See * {{LookupCriteriaGeneratoreBase.getCollectionCriteriaFromMapUsingPrimaryKeysOnly}} * {{LookupCriteriaGeneratoreBase.doesLookupFieldTreatWildcardsAndOperatorsAsLiteral}} * {{LookupCriteriaGeneratorQBC.doesLookupFieldTreatWildcardsAndOperatorsAsLiteral}} |
| Assignee | Aaron Hamid [ ahamid ] | Jonathan Keller [ jkeller ] |
| Epic Link |
|
| Original Estimate | 3 hours [ 10800 ] |
| Remaining Estimate | 3 hours [ 10800 ] |
| Workflow | custom [ 198660 ] | Copy of custom for rice [ 207960 ] |
| Workflow | Copy of custom for rice [ 207960 ] | custom [ 217708 ] |
| Workflow | custom [ 217708 ] | Rice Workflow [ 227456 ] |
| Rank | Ranked higher |
| Rank | Ranked lower |
| Rank | Ranked lower |
| Sprint | 2.4.0-rc1 Sprint 8 [ 247 ] |
| Sprint | 2.4.0-rc1 Sprint 8 [ 247 ] | 2.4.0-rc1 Sprint 7 [ 246 ] |
| Rank | Ranked higher |
| Sprint | 2.4.0-rc1 Sprint 7 [ 246 ] | 2.4.0-rc1 Sprint 8 [ 247 ] |
| Sprint | 2.4.0-rc1 Sprint 8 [ 247 ] |
| Rank | Ranked lower |
| Sprint | 2.4.0-rc1 Sprint 7 [ 246 ] |
| Rank | Ranked lower |
| Sprint | 2.4.0-rc1 Sprint 7 [ 246 ] | 2.4.0-rc1 Sprint 7, 2.4.0-rc1 Sprint 8 [ 246, 247 ] |
| Rank | Ranked higher |
| Epic Link |
|
| Fix Version/s | 2.4.1 [ 17516 ] | |
| Fix Version/s | 2.4 [ 16913 ] |
| Fix Version/s | 2.5 [ 17044 ] | |
| Fix Version/s | 2.4.1 [ 17516 ] |
| Rank | Ranked higher |
| Fix Version/s | 2.6 [ 17820 ] | |
| Fix Version/s | 2.5 [ 17044 ] |
| Labels | Old |
