OpenJPA
  1. OpenJPA
  2. OPENJPA-1913

If fetch-groups is used, detaching an entity will lead to all lazy loaded members get reset to null

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Not a Problem
    • Affects Version/s: 2.1.0
    • Fix Version/s: None
    • Component/s: kernel
    • Labels:
      None

      Description

      If I use openjpa.DetachState=fetch-groups and detach an entity with a lazy loaded list, this list gets reset to null.

      An example:

      class @Entity Person {
      private String name;

      @OneToMany(mappedBy = "group", cascade =

      {CascadeType.ALL}

      )
      private List<Subscription> subscriptions = new ArrayList<Subscription>();
      ...}

      I load the Person and access the subscriptions inside a transaction. I get a person instance with e.g. 3 subscriptions.
      If I now close the EntityManager and my person gets detached, the subscriptions list is suddenly null!

      1. OPENJPA-1913-enhancer-fix.patch
        2 kB
        Mark Struberg
      2. OPENJPA-1913-test.patch
        9 kB
        Mark Struberg

        Activity

        Hide
        Mark Struberg added a comment -

        Patch against the current trunk to demonstrate the problem.
        Please note that the lazyChildren will remain in the parent entity if fetch-groups is not used or if EAGER fetching is used. So this is definitely a bug

        Show
        Mark Struberg added a comment - Patch against the current trunk to demonstrate the problem. Please note that the lazyChildren will remain in the parent entity if fetch-groups is not used or if EAGER fetching is used. So this is definitely a bug
        Hide
        Mark Struberg added a comment -

        this small patch fixes a few errors I had in the enhancer section.

        Show
        Mark Struberg added a comment - this small patch fixes a few errors I had in the enhancer section.
        Hide
        Jeremy Bauer added a comment -

        I did some debugging and a little more experimentation and I believe OpenJPA is working as designed. Using a DetachState of fgs results in a detached entity with only those fields in the specified fetch group. By default, OpenJPA uses the "default" fetch group and that fetch group contains primary keys, version fields, and eager fetch fields. If you apply a non-default fetch group (specified dynamically or via the openjpa.FetchGroups property) fields defined as EAGER - but not included in the specified fetch group - will not be included in detached entity (they'll be null). It is the correlation of EAGER/LAZY to the default fetch group that muddies the waters a bit. Also, one tends to think of fetch groups as a load operation, but in this case it applies to detachment as well.

        While it isn't terribly intuitive, using fgs may be useful if you are detaching and only want to provide a client an entity populated with only those fields defined in the fetch group. It sounds like what you may be looking for is a hybrid "loaded + fgs" option that preserves loaded fields and also loads any unloaded fields that are defined in the fetch group upon detachment.

        Show
        Jeremy Bauer added a comment - I did some debugging and a little more experimentation and I believe OpenJPA is working as designed. Using a DetachState of fgs results in a detached entity with only those fields in the specified fetch group. By default, OpenJPA uses the "default" fetch group and that fetch group contains primary keys, version fields, and eager fetch fields. If you apply a non-default fetch group (specified dynamically or via the openjpa.FetchGroups property) fields defined as EAGER - but not included in the specified fetch group - will not be included in detached entity (they'll be null). It is the correlation of EAGER/LAZY to the default fetch group that muddies the waters a bit. Also, one tends to think of fetch groups as a load operation, but in this case it applies to detachment as well. While it isn't terribly intuitive, using fgs may be useful if you are detaching and only want to provide a client an entity populated with only those fields defined in the fetch group. It sounds like what you may be looking for is a hybrid "loaded + fgs" option that preserves loaded fields and also loads any unloaded fields that are defined in the fetch group upon detachment.
        Hide
        Mark Struberg added a comment -

        hmm, interesting point. But of course, any non-specced openjpa feature must not break a spec conform CascadeType.DETACH and CascadeType.MERGE! This always must have priority over FetchGroups, otherwise we would break the spec.

        Show
        Mark Struberg added a comment - hmm, interesting point. But of course, any non-specced openjpa feature must not break a spec conform CascadeType.DETACH and CascadeType.MERGE! This always must have priority over FetchGroups, otherwise we would break the spec.
        Hide
        Rick Curtis added a comment -

        @Mark – I'm pretty sure that we have numerous OpenJPA 'features' that make us non-complaint... as long as your stay to javax.persistence.blah configuration, you'll stay compliant. Once you drop into OpenJPA specific stuff, all bets are off.

        Show
        Rick Curtis added a comment - @Mark – I'm pretty sure that we have numerous OpenJPA 'features' that make us non-complaint... as long as your stay to javax.persistence.blah configuration, you'll stay compliant. Once you drop into OpenJPA specific stuff, all bets are off.
        Hide
        Albert Lee added a comment -

        Per Jeremy and Rick, this is worked as designed.

        Show
        Albert Lee added a comment - Per Jeremy and Rick, this is worked as designed.

          People

          • Assignee:
            Jeremy Bauer
            Reporter:
            Mark Struberg
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development