OpenJPA
  1. OpenJPA
  2. OPENJPA-2141

Lazy fetch of embedded attributes does not work properly

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2.1, 2.3.0
    • Fix Version/s: None
    • Component/s: jdbc
    • Labels:
      None

      Description

      OpenJPA's @Persistent annotation and configuration via OpenJPA's xml extensions provide a mechanism to mark embedded fields lazy. When trying to use this facility I found a couple bugs.
      Bug 1: The xml extension does not process the fetch attribute, so the field is never marked lazy.
      Bug 2: If marked lazy via the annotation or xml (with a fix) the lazy field does not get loaded along with the entity (as expected), but then will not load when accessed.

        Activity

        Hide
        Mark Struberg added a comment -

        I've now created OPENJPA-2179 for this.

        Show
        Mark Struberg added a comment - I've now created OPENJPA-2179 for this.
        Hide
        Mark Struberg added a comment -

        txs, I'll create a new issue.

        Show
        Mark Struberg added a comment - txs, I'll create a new issue.
        Hide
        Jeremy Bauer added a comment -

        Mark - given that none of your fields are marked lazy, I'd guess what you've described is a separate issue. It looks like our logic to determine whether a lob can be fetched inline may need to be reviewed for certain queries. Each DB vendor also has various levels of support for inlining so what you see could be DB specific as well. Unless the fields in the embeddable are tagged as lazy, I'm not sure why we'd need to fetch them separately. That sounds like a bug.

        Any chance you can provide a testcase? I could at least verify what I've added for this JIRA hasn't broken anything.

        Show
        Jeremy Bauer added a comment - Mark - given that none of your fields are marked lazy, I'd guess what you've described is a separate issue. It looks like our logic to determine whether a lob can be fetched inline may need to be reviewed for certain queries. Each DB vendor also has various levels of support for inlining so what you see could be DB specific as well. Unless the fields in the embeddable are tagged as lazy, I'm not sure why we'd need to fetch them separately. That sounds like a bug. Any chance you can provide a testcase? I could at least verify what I've added for this JIRA hasn't broken anything.
        Hide
        Mark Struberg added a comment -

        Actually I found a bug which could be related to this.

        I have an Entity (Course) with a simple @Embedded field and a @Lob. I do not use any LAZY attribution on them!

        If I do a normal em.find, the entity will be loaded as a whole (all the fields, including the embedded and the lob will be fetched immediately).
        Sidenote: the Lecturer referred in the select is defined as
        @OneToMany(mappedBy = "course",
        cascade =

        {CascadeType.PERSIST, CascadeType.REMOVE, CascadeType.MERGE}

        ,
        orphanRemoval = true, fetch = FetchType.EAGER)
        @OrderColumn(name = "POSITION")
        private List<Lecturer> lecturers;

        The following selects DO work

        • "select c from Course c join c.lecturers l "
        • "select distinct c from Course c"

        The following selects create tons of subqueries! 1 separate sub-query for each @Embedded field, and also for each @Lob

        • "select distinct c from Course c join c.lecturers l "
        • "select distinct c from Lecturer l join l.course c"
        • "select c from Lecturer l join l.course c"

        Should I create a separate issue or do you think it's related?

        Show
        Mark Struberg added a comment - Actually I found a bug which could be related to this. I have an Entity (Course) with a simple @Embedded field and a @Lob. I do not use any LAZY attribution on them! If I do a normal em.find, the entity will be loaded as a whole (all the fields, including the embedded and the lob will be fetched immediately). Sidenote: the Lecturer referred in the select is defined as @OneToMany(mappedBy = "course", cascade = {CascadeType.PERSIST, CascadeType.REMOVE, CascadeType.MERGE} , orphanRemoval = true, fetch = FetchType.EAGER) @OrderColumn(name = "POSITION") private List<Lecturer> lecturers; The following selects DO work "select c from Course c join c.lecturers l " "select distinct c from Course c" The following selects create tons of subqueries! 1 separate sub-query for each @Embedded field, and also for each @Lob "select distinct c from Course c join c.lecturers l " "select distinct c from Lecturer l join l.course c" "select c from Lecturer l join l.course c" Should I create a separate issue or do you think it's related?
        Hide
        Jeremy Bauer added a comment -

        Note: the fix I committed does not yet handle the "embedded" attribute via XML. The field still needs to be annotated or tagged embeddable in xml. There's a bit more code and testing to handle this attribute. I plan to work on that item in the future.

        Show
        Jeremy Bauer added a comment - Note: the fix I committed does not yet handle the "embedded" attribute via XML. The field still needs to be annotated or tagged embeddable in xml. There's a bit more code and testing to handle this attribute. I plan to work on that item in the future.
        Hide
        Jeremy Bauer added a comment -

        Fix and test committed to trunk (2.3.0) under rev 1293250.

        Show
        Jeremy Bauer added a comment - Fix and test committed to trunk (2.3.0) under rev 1293250.
        Hide
        Jason Pyeron added a comment -

        Do you think you could attach an example that I can use for testing?
        Do you have the patch for the xml "fix"?

        Thanks

        Show
        Jason Pyeron added a comment - Do you think you could attach an example that I can use for testing? Do you have the patch for the xml "fix"? Thanks

          People

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

            Dates

            • Due:
              Created:
              Updated:

              Development