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

Select Lists (call to ValuesFinder class) not updated frequently enough

    Details

    • Similar issues:
      KULRICE-1842GlobalVaribales KualiForm not available for ValuesFinder classes
      KULRICE-1808PersistableBusinessObjectValuesFinder is not working for inquiries that have child objects with ValuesFinder populated select lists
      KULRICE-5697Add the ability to parameterize a ValuesFinder
      KULRICE-6984Role Delegate APIs are not granular enough
      KULRICE-1411PersistableBusinessObjectValuesFinder is not working when replaced by the ValuesFinder Classes
      KULRICE-1502add @Cached to service methods that are called frequently
      KULRICE-1633Implement method of populating drop downs for search and rule attributes as well as edoc lite fields using simpler method than ValuesFinder classes
      KULRICE-4207Have UIDocumentService call the DTO's and not the underlying impl classes
      KULRICE-10752BusinessObjectDaoProxy called with non-legacy class: class AccountManager
      KULRICE-3681Doc Search: SearchableAttributes: Multi-Select: ClassCastExecption
    • Rice Module:
      KNS
    • Application Requirement:
      KC

      Description

      We have a test class in KRA org.kuali.kra.proposaldevelopment.web.AbstractsPanelWebTest that has 6 failing methods following the latest Rice 0.9.2 update. It appears these tests are failing because the abstracts select list isn't being updated based on which abstracts have been added to the document. This is a function of the AbstractTypeValuesFinder which doesn't appear to be being called as frequently as it was in the past. Before this update, when an abstract was added to our document, the page was refreshed and the ValuesFinder class was called to get the values for the abstract type select list. This ValuesFinder gets the document from the form in the GlobalVariables (previous enhancement to add context to values finders classes) and it only adds abstract types to the list if there isn't an abstract of that type existing in the document. I don't have time right now to add a test for this to Rice, but you can look at KRA for a good example.

        Issue Links

          Activity

          Hide
          Bryan Hutchinson added a comment -

          Warren, I'm not sure I understand your last comment, could you provide some more details. One thing specifically I'm wondering is where/how would users pass in ValueFinder class objects? Thanks.

          Show
          Bryan Hutchinson added a comment - Warren, I'm not sure I understand your last comment, could you provide some more details. One thing specifically I'm wondering is where/how would users pass in ValueFinder class objects? Thanks.
          Hide
          Warren Liang added a comment -

          Bryan,

          I just committed a change to the rice-release-0-9-2-kfs-performance-br branch about 3am ET today morning to allow for more granular caching. I was going to write a confluence page for more complete details to retain for posterity, but in short, here's what you do. I'll mark this issue as resolved when I complete the confluence page.

          Override the populate method in your form (remember to call super.populate), and calling the following methods (remember to do the instanceof check that I showed in the previous code example):

          To cache (or uncache) all of the KeyValueFinders on the form, this is the new method:
          /**

          • Sets whether the results of all KeyValueFinders should be cached so that the finders will not be
          • invoked multiple times, leading to a performance improvement. This is the base setting for
          • all value finders on a form, and may be overridden by a call to {@link #setKeyValueFinderCachability(Class, Boolean)}

            .

          • @param cacheKeyValueFinderResultsByDefault
            */
            public void setDefaultKeyValueFinderCachability(boolean cacheKeyValueFinderResultsByDefault)

          To cache (or uncache) instances of a particular class of KeyValueFinders, use this method:
          /**

          • Overrides the default setting for cachability for the specified KeyValueFinder.
          • @param clazz the KeyValueFinder to cache (or not cache)
          • @param cachability {@link Boolean#TRUE}

            if the results of the value finder are to be cached (regardless of default setting),

          • {@link Boolean#FALSE}

            if the results of the key/value finder are <b>not</b> to be cached, and <code>null</code> if cachability

          • should be based on the default setting specified when calling {@link #setDefaultKeyValueFinderCachability(boolean)}

            */
            public void setKeyValueFinderCachability(Class clazz, Boolean cachability)

          Let me know if you have any questions.

          Show
          Warren Liang added a comment - Bryan, I just committed a change to the rice-release-0-9-2-kfs-performance-br branch about 3am ET today morning to allow for more granular caching. I was going to write a confluence page for more complete details to retain for posterity, but in short, here's what you do. I'll mark this issue as resolved when I complete the confluence page. Override the populate method in your form (remember to call super.populate), and calling the following methods (remember to do the instanceof check that I showed in the previous code example): To cache (or uncache) all of the KeyValueFinders on the form, this is the new method: /** Sets whether the results of all KeyValueFinders should be cached so that the finders will not be invoked multiple times, leading to a performance improvement. This is the base setting for all value finders on a form, and may be overridden by a call to {@link #setKeyValueFinderCachability(Class, Boolean)} . @param cacheKeyValueFinderResultsByDefault */ public void setDefaultKeyValueFinderCachability(boolean cacheKeyValueFinderResultsByDefault) To cache (or uncache) instances of a particular class of KeyValueFinders, use this method: /** Overrides the default setting for cachability for the specified KeyValueFinder. @param clazz the KeyValueFinder to cache (or not cache) @param cachability {@link Boolean#TRUE} if the results of the value finder are to be cached (regardless of default setting), {@link Boolean#FALSE} if the results of the key/value finder are <b>not</b> to be cached, and <code>null</code> if cachability should be based on the default setting specified when calling {@link #setDefaultKeyValueFinderCachability(boolean)} */ public void setKeyValueFinderCachability(Class clazz, Boolean cachability) Let me know if you have any questions.
          Hide
          Bryan Hutchinson added a comment -

          Unfortunately, I don't think this will achieve the desired result for KRA. One of the enhancements that we requested and that has been implemented in Rice was the ability to add context for ValuesFinder classes (see https://test.kuali.org/confluence/x/mq for more info). As part of this enhancement, a generic ValuesFinder class was created that could be reused for multiple BOs. As a result, it's conceivable that we would be passing the same class to this method for multiple select lists, which would not give us that granularity of control that we want.

          I think what really needs to happen for this is what was discussed at last Wednesday's Rice Integration meeting: a proposal for this functionality needs to be documented and presented at that meeting for review.

          Show
          Bryan Hutchinson added a comment - Unfortunately, I don't think this will achieve the desired result for KRA. One of the enhancements that we requested and that has been implemented in Rice was the ability to add context for ValuesFinder classes (see https://test.kuali.org/confluence/x/mq for more info). As part of this enhancement, a generic ValuesFinder class was created that could be reused for multiple BOs. As a result, it's conceivable that we would be passing the same class to this method for multiple select lists, which would not give us that granularity of control that we want. I think what really needs to happen for this is what was discussed at last Wednesday's Rice Integration meeting: a proposal for this functionality needs to be documented and presented at that meeting for review.
          Hide
          Warren Liang added a comment -

          Bryan, I'm interpreting that you're saying that you want to be able to cache KeyValueFinder results, but that instead of using the class name as the sole cache key, you want to use the class name AND the context information as the cache key.

          FYI, a cache entry's lifetime is the lifetime of the request. Therefore, if a drop down box is only rendered once, then there's no performance improvement. Are you rendering the same drop down (i.e. same finder class and context info) multiple times on the same page?

          Show
          Warren Liang added a comment - Bryan, I'm interpreting that you're saying that you want to be able to cache KeyValueFinder results, but that instead of using the class name as the sole cache key, you want to use the class name AND the context information as the cache key. FYI, a cache entry's lifetime is the lifetime of the request. Therefore, if a drop down box is only rendered once, then there's no performance improvement. Are you rendering the same drop down (i.e. same finder class and context info) multiple times on the same page?
          Hide
          Ailish Byrne added a comment -

          lin-long added code to clear out the map between requests. this resolved the immediate issue kra was experiencing since their forms are in session instead of request. i created a future request to introduce further flexibility in this functionality, but neither kra nor kfs need that flexibility right now. so, it is not a high priority

          Show
          Ailish Byrne added a comment - lin-long added code to clear out the map between requests. this resolved the immediate issue kra was experiencing since their forms are in session instead of request. i created a future request to introduce further flexibility in this functionality, but neither kra nor kfs need that flexibility right now. so, it is not a high priority

            People

            • Assignee:
              Warren Liang
              Reporter:
              Bryan Hutchinson
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved:

                Structure Helper Panel