JPA default fetch type

后端 未结 4 758
小鲜肉
小鲜肉 2021-02-07 03:14

From my understanding @OneToOne and @ManyToOne JPA annotations do an eager fetch. I want these to be lazily loaded in my application, or a

相关标签:
4条回答
  • 2021-02-07 03:31

    To date, I have chosen to have Hibernate follow the JPA spec in terms of mapping via annotations simply because I have not received any feature requests for making it configurable, which was surprising TBH. As you point out, since Hibernate 3.0 what you want has been the default set up when using hbm.xml mapping files.

    Allowing this via configuration would not violate the spec as another answer suggested.

    So long story short, no it is not possible today. Create a feature request if you'd like to see that be configurable.

    0 讨论(0)
  • 2021-02-07 03:31

    JPA Spec assumes that in general most of the applications will require the singleton relations by default be eager, whereas multi value relations by default be lazy. And at least in my own experience, this is generally the desired architecture. This makes sense, since singleton relations require no significant additional performance in JPA layer and DB layer to create a singleton join on foreign key. However, in contradiction to that, multi valued attributes create either N + 1 problem or large cartesian resultsets that get inflates exponentially as the number of elements in collections and number of joins increase when join fetch is used (Although Hibernate specifically cannot handle join fetches on 2+ eager associations).

    Having said that, as for your suggestion, you require a specific (to be honest not completely uncommon) case to be addressed. Now you have a single case but as there are hundreds of cases like that. So to write specifications you need to draw a line between the generalization and granularity.

    If I were in your shoes, if you think this an absolutely useful feature to be added to JPA Specification, I would submit it to the JCP. On the other hand if you get this(, that and that...) addressed in a specific implementation then you end up in so-called vendor-lockin. So I would work an extra hour to set the lazy fetch on @ManyToOne @OneToOne attributes and stay vendor-free, therefore by sticking to the specification if say a new JPA implementation comes along that is over 15x faster then Hibernate (or whatever implementation you use), it would take little to no effort to move your project that new JPA implementation.

    0 讨论(0)
  • 2021-02-07 03:33

    From my understanding @oneToOne and @ManyToOne JPA annotations do an eager fectch.

    JPA guarantees eager-loading on single-valued relationships, if not otherwise declared by annotation or within the persistence XML. For Collection-valued relationships it defaults to lazy loading, but lazy loading is (just) a hint to the persistence provider supporting JPA, so you cannot rely on it, and have to check for the specific provider (e.g. Hibernate, OpenJPA). See this link as a reference, and for more insight.

    0 讨论(0)
  • 2021-02-07 03:53

    no way. there is nothing about changing global fetching strategy in JPA specification. JPA offers for 1-1/N-1 associations EAGER fetching, whereas for 1-N/M-N it is LAZY. All JPA implementations should follow the specification to be compliant. I think, it is better that the application developer can't change this default beheavior globally, since these are the best practices in almost most cases unless you've just one type of association between all entities, like 1-1. think about, that you could set it to "EAGER" in an application, which contains a really rich entity model with complex relations and millions of data in the database. Overriding the fetching strategy per association manually allows the developer to take the responsibility about what will next happen. it is not error prone, instead, a powerful feature.

    0 讨论(0)
提交回复
热议问题