jpa-spec
  1. jpa-spec
  2. JPA_SPEC-20

add FetchType.LAZY/EAGER to @Lob fields and @Embeddable

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Labels:
      None

      Description

      Afaik there is currently no way to specify a @Lob field as being lazy loaded.

      BLOBS and LOBS often need a big amount of memory and are expensive to fetch from the database.

      What about adding something like:

      public class MyEntity {
      
        @Lob(FetchType.LAZY)
        private String someHistoryData;
      
      }
      

      Currently one always needs to create explicit list objects which get filled with 'new' in JPQL to not trash the database.

      The same goes for @Embeddable. Though not needed that desperately it could be useful as well. (The whole Embedded would get lazily fetched when a single attribute of it is read).

        Activity

        Hide
        Mark Struberg added a comment -

        small note: it's for sure better to define the FetchType in each @Embedded and not in @Embeddable.

        Show
        Mark Struberg added a comment - small note: it's for sure better to define the FetchType in each @Embedded and not in @Embeddable.
        Hide
        mkeith added a comment -

        You can actually combine @Lob with @Basic, allowing you to specify a fetch type for any Lob attribute. I think this will give you what you want.

        As far as Embedded objects go, any one of the embedded attributes can be individually specified to be lazy loaded but there is not currently a standard way to say that the embedded object should be lazy loaded as an object. My personal opinion is that if you get to that point then you are probably bordering on considering the embeddable as an independent privately owned entity and should make a relationship out of it instead of an embeddable, but that may just be me. We could get to the stage of adding a fetchType element on @Embedded, or we could handle this case through entity fetch groups.

        Show
        mkeith added a comment - You can actually combine @Lob with @Basic, allowing you to specify a fetch type for any Lob attribute. I think this will give you what you want. As far as Embedded objects go, any one of the embedded attributes can be individually specified to be lazy loaded but there is not currently a standard way to say that the embedded object should be lazy loaded as an object. My personal opinion is that if you get to that point then you are probably bordering on considering the embeddable as an independent privately owned entity and should make a relationship out of it instead of an embeddable, but that may just be me. We could get to the stage of adding a fetchType element on @Embedded, or we could handle this case through entity fetch groups.
        Hide
        ldemichiel added a comment -

        I think it is reasonable to add FetchType to @Embedded. When we first introduced embeddables they were more limited in terms of what attributes they could have.

        Show
        ldemichiel added a comment - I think it is reasonable to add FetchType to @Embedded. When we first introduced embeddables they were more limited in terms of what attributes they could have.
        Hide
        Mark Struberg added a comment -

        Mike, Linda, thanks for pointing me to @Basic. I was actually not aware that I can use both @Basic and @Column on the same field - my fault. I always thought that @Column was a successor of @Basic, mostly because they have conflicting properties. E.g. having a

        @Basic(optional=false)
        @Column(nullable=true)
        private String xxx;

        lets me without a clue what should happen. But that is certainly another (minor) problem.

        As for FetchType for Embedded fields: this is certainly not as big as an issue for the (now solved) @Lob question. Downgrade to minor? txs!

        Show
        Mark Struberg added a comment - Mike, Linda, thanks for pointing me to @Basic. I was actually not aware that I can use both @Basic and @Column on the same field - my fault. I always thought that @Column was a successor of @Basic, mostly because they have conflicting properties. E.g. having a @Basic(optional=false) @Column(nullable=true) private String xxx; lets me without a clue what should happen. But that is certainly another (minor) problem. As for FetchType for Embedded fields: this is certainly not as big as an issue for the (now solved) @Lob question. Downgrade to minor? txs!
        Hide
        ldemichiel added a comment -

        Downgraded priority to reflect comments

        Show
        ldemichiel added a comment - Downgraded priority to reflect comments

          People

          • Assignee:
            ldemichiel
            Reporter:
            Mark Struberg
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: