Uploaded image for project: 'Rave'
  1. Rave
  2. RAVE-876

Change to fetch Collections on JpaWidget lazily instead of eagerly.

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Open
    • Trivial
    • Resolution: Unresolved
    • None
    • None
    • rave-jpa
    • None

    Description

      On page load there are a number of objects that get populated (either from cache, if implemented, or via database provider) for the @JoinColumn attributes on a JPAWidget because FetchType is set to EAGER.

      For a vanilla instance of Rave this is overly excessive since the Widget in order to render doesn't require Ratings, Comments, Tags, or Categories this should be set to FetchType.LAZY to allow the JPA provider the ability to add efficiency in the server's time rendering the base page layout / html.

      ---------------------- initial email contents ----------------------

      I have been spending sometime in looking at the effecency of a RAVE extension and discovered that on initial page load (and every page load after that) there is some excessive database / cache calls being made to populate the model. Taking a look at the JPA configuration I pinned it down to how OpenJPA is creating the JpaWidget model as there are a number of parameters being fetched, though never used the following list shows this:

      • List<JpaWidgetComment> comments (ln #184)
      • List<JpaWidgetRating> ratings (ln #202)
      • List<JpaWidgetTag> tags (ln #206)
      • List<JpaCategory> categories (ln #214)

      These attributes are only displayed within the store and IMHO are not needed to be EAGERLY fetched. Changing this to the more common FetchType.LAZY. The default usually is to load Collections lazily while loading attributes eagerly. [1]

      If there aren't any objections I am going to submit a patch this afternoon, created a ticket within JIRA (my first contribution to RAVE!)

      Attachments

        Activity

          People

            Unassigned Unassigned
            tmack Trevor Mack
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:

              Time Tracking

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