Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-9489

Determine best way to determine whether KRAD criteria fields treat wildcards and operators as literals

    Details

    • Type: New Feature New Feature
    • Status: Open Open
    • Priority: Critical 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:
    • Similar issues:
      KULRICE-11964Lookup criteria generator requests view instance to determine wildcard treatment
      KULRICE-10937Determine the best way to handle "refresh reference" and leverage EntityManager.getReference for JPA
      KULRICE-13235Clear up the KIM qualifier question as to whether they should match by wildcard
      KULRICE-10432Allow Action Buttons to determine whether they show on the Old or New sides of a Maintenance document
      KULRICE-5069Determine best strategy for declaring/throwing exceptions from (remote) service layer
      KULRICE-5941Determine the proper way to handle client-side caching and eviction operations
      KULRICE-9102Determine how best to handle linking to DocumentHeader using JPA as was done with OJB
      KULRICE-10350Determine whether multivalue lookups can be used for EBOs
      KULRICE-9885Disabled wildcard lookups still honor wildcards
      KULRICE-4275Determine how best to position and package the cornell pdf enhancement
    • 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

        Activity

        Hide
        Eric Westfall added a comment -

        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.

        Show
        Eric Westfall added a comment - 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.
        Hide
        Jonathan Keller added a comment -

        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.

        Show
        Jonathan Keller added a comment - 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.

          People

          • Assignee:
            Jonathan Keller
            Reporter:
            Eric Westfall
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 3 hours
              3h
              Remaining:
              Remaining Estimate - 3 hours
              3h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Agile

                  Structure Helper Panel