OpenJPA
  1. OpenJPA
  2. OPENJPA-2020

Make some members of StateManagerImpl protected to allow for greater extensability

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.0, 2.2.0
    • Fix Version/s: 2.1.1, 2.2.0
    • Component/s: kernel
    • Labels:
      None

      Description

      With this JIRA I'm going to change a number of methods / fields to protected to allow for greater extensibility.

        Issue Links

          Activity

          Hide
          Pinaki Poddar added a comment -

          Making carte blanche changes sensitive/critical constructs to private fields as protected is a poor design practice.

          We have met similar situation before. And the good practice is to
          a) provide the nature and reason of extension one is looking for. This way some alternatives can be suggested that does not require such changes.
          b) It is understood that some work may require some degree of access relaxation. But it is more prudent to make those relaxation as and when they are required

          Show
          Pinaki Poddar added a comment - Making carte blanche changes sensitive/critical constructs to private fields as protected is a poor design practice. We have met similar situation before. And the good practice is to a) provide the nature and reason of extension one is looking for. This way some alternatives can be suggested that does not require such changes. b) It is understood that some work may require some degree of access relaxation. But it is more prudent to make those relaxation as and when they are required
          Hide
          Pinaki Poddar added a comment -

          The committer is requested to response to the concerns as expressed above.

          Show
          Pinaki Poddar added a comment - The committer is requested to response to the concerns as expressed above.
          Hide
          Rick Curtis added a comment -

          > Making carte blanche changes sensitive/critical constructs to private fields as protected is a poor design practice.
          Or perhaps the original designer of this code didn't think that someone would want to extend this object.?

          I'm currently reviewing the code as I am pretty certain that I didn't need to open up most of the members that I did.

          Show
          Rick Curtis added a comment - > Making carte blanche changes sensitive/critical constructs to private fields as protected is a poor design practice. Or perhaps the original designer of this code didn't think that someone would want to extend this object.? I'm currently reviewing the code as I am pretty certain that I didn't need to open up most of the members that I did.
          Hide
          Rick Curtis added a comment -

          The short answer of where I'm heading is that I need access to the _fieldImpl Object[]. Either that method needs to be marked protected, or a getter would need to be added. This array is used in some instances to store foreign keys of lazy fields.

          Hopefully this isn't too cryptic of an answer...?

          Show
          Rick Curtis added a comment - The short answer of where I'm heading is that I need access to the _fieldImpl Object[]. Either that method needs to be marked protected, or a getter would need to be added. This array is used in some instances to store foreign keys of lazy fields. Hopefully this isn't too cryptic of an answer...?
          Hide
          Rick Curtis added a comment -

          Closing resolved issues.

          Show
          Rick Curtis added a comment - Closing resolved issues.

            People

            • Assignee:
              Rick Curtis
              Reporter:
              Rick Curtis
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development