非一致性訪存系統

在使用ORM工具時，每個人都承認數據庫設計和實體到表映射的重要性。 這些方面引起了很多關注，而諸如獲取策略之類的事情可能只是推遲了。

我認為，不應將實體獲取策略與實體映射設計分開，因為除非經過適當設計，否則它可能會影響整體應用程序性能。

在Hibernate和JPA如此流行之前，設計每個查詢需要付出大量的努力，因為您必須明確地選擇要從中選擇的所有聯接以及所有您感興趣的列。足夠，DBA可以優化運行緩慢的查詢。

在JPA時代，JPA-QL或HQL查詢正在獲取實體及其一些關聯關系。 這使開發變得輕松，因為它使我們免于手動選擇我們感興趣的所有表字段的麻煩，有時會自動生成聯接或其他查詢來滿足我們的需求。

這是一把雙刃劍。 一方面，您可以更快地交付功能，但如果自動生成SQL查詢效率不高，則應用程序的整體性能可能會受到嚴重影響。

那么，實體獲取策略是什么？

當JPA加載實體時，它也會同時加載所有EAGER或“ join fetch”關聯。 只要打開持久性上下文，在LAZY關聯中導航也將通過其他已執行的查詢來獲取那些關聯。

默認情況下，將更容易地自動獲取JPA @ManyToOne和@OneToOne批注，而將@OneToMany和@ManyToMany關系視為LAZY。 這是默認的策略，并且Hibernate不會神奇地優化您的對象檢索，它只會執行所指示的操作。

盡管小型項目不需要全面的實體獲取計劃，但中大型應用程序永遠都不應忽略它。

從一開始就計劃獲取策略，并在整個開發周期中進行調整，這并不是“過早的優化”，這只是任何ORM設計的自然組成部分。

缺省的獲取策略是您通過JPA映射定義的策略，而手動連接獲取是使用JPA-QL查詢時的策略。

我能給您的最佳建議是贊成手動獲取策略（在使用獲取操作符的JPA-QL查詢中定義）。 雖然總是急切地獲取某些@ManyToOne或@OneToOne關聯，但在大多數情況下，并不是每個獲取操作都需要它們。

對于兒童協會，將它們標記為LAZY并僅在需要時才“聯接提取”它們總是比較安全的，因為它們可以輕松生成帶有不需要聯接的大型SQL結果集。

將大多數關聯定義為LAZY要求我們使用“ join fetch” JPA-QL運算符，并且僅檢索滿足給定請求所需的關聯。 如果您忘記正確地“聯接提取”，則在瀏覽惰性關聯時，持久性上下文將代表您運行查詢，這可能會產生“ N + 1”問題，或者可能是通過簡單聯接檢索到的其他SQL查詢首先。

作為一個具體的例子，讓我們從下圖開始：

產品實體關聯映射為：

@ManyToOne(fetch = FetchType.EAGER) @JoinColumn(name = "company_id", nullable = false) private Company company;@OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL, mappedBy = "product", optional = false) private WarehouseProductInfo warehouseProductInfo;@ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "importer_id") private Importer importer;@OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL, mappedBy = "product", orphanRemoval = true) @OrderBy("index") private Set<Image> images = new LinkedHashSet<Image>();

大多數關聯都標記為LAZY，因為每次加載產品時都不需要獲取所有關聯。 僅在顯示庫存信息時才需要倉庫。 導入程序僅在某些顯示中使用，我們將在必要時提取它。 圖像是惰性的，因為并非所有視圖都需要顯示這些圖像。

因為我們所有的觀點都需要它，所以只有公司熱切地求助，并且在我們的應用程序中，始終必須在給定公司的背景下考慮產品。

即使@ManyToOne默認使用EAGER fetch選項，最好還是顯式地設置默認的獲取策略（這會使代碼更具自描述性）。

用例1：通過id加載產品將生成以下SQL

SELECT product0_.id AS id1_7_1_,product0_.code AS code2_7_1_,product0_.company_id AS company_4_7_1_,product0_.importer_id AS importer5_7_1_,product0_.name AS name3_7_1_,company1_.id AS id1_1_0_,company1_.name AS name2_1_0_ FROM product product0_ INNER JOIN company company1_ ON product0_.company_id = company1_.id WHERE product0_.id = ?

每次我們通過實體管理器加載時，都會使用默認的獲取策略，這意味著公司將與我們選擇的產品一起獲取。

用例2：通過JPA-QL查詢選擇產品（繞過Persistence Context一級緩存）

entityManager.createQuery("select p " +"from Product p " +"where p.id = :productId", Product.class) .setParameter("productId", productId) .getSingleResult();

這將執行以下SQL查詢：

SELECT product0_.id AS id1_7_,product0_.code AS code2_7_,product0_.company_id AS company_4_7_,product0_.importer_id AS importer5_7_,product0_.name AS name3_7_ FROM product product0_ WHERE product0_.id = ?

因此，使用JPA-QL會覆蓋默認的提取策略，但是如果我們要瀏覽惰性關聯，它仍然使我們容易受到攻擊。 如果Persistence Context關閉，則在訪問惰性關系時會收到LazyInitializationException，但如果未關閉，則會生成其他選擇查詢，這可能會影響應用程序性能。

用例3：選擇具有相關倉庫和進口商關聯的產品列表：

entityManager.createQuery("select p " +"from Product p " +"inner join fetch p.warehouseProductInfo " +"inner join fetch p.importer", Product.class) .getResultList();

這將生成以下SQL：

SELECT product0_.id AS id1_7_0_,warehousep1_.id AS id1_11_1_,importer2_.id AS id1_3_2_,product0_.code AS code2_7_0_,product0_.company_id AS company_4_7_0_,product0_.importer_id AS importer5_7_0_,product0_.name AS name3_7_0_,warehousep1_.quantity AS quantity2_11_1_,importer2_.name AS name2_3_2_ FROM product product0_ INNER JOIN warehouseproductinfo warehousep1_ ON product0_.id = warehousep1_.id INNER JOIN importer importer2_ ON product0_.importer_id = importer2_.id

在這里，您可以看到JPA-QL顯式提取策略將覆蓋默認策略。 由于我們尚未指定與Company的“ join fetch”，因此EAGER關聯將被忽略。

用例4：在顯式加入獲取產品的同時選擇一系列圖像，即使所選實體不是我們要覆蓋其策略的實體，也將覆蓋默認策略：

entityManager.createQuery("select i " +"from Image i " +"inner join fetch i.product p " +"where p.id = :productId", Image.class) .setParameter("productId", productId) .getResultList();

這將生成以下SQL：

SELECT image0_.id AS id1_2_0_,product1_.id AS id1_7_1_,image0_.index AS index2_2_0_,image0_.name AS name3_2_0_,image0_.product_id AS product_4_2_0_,product1_.code AS code2_7_1_,product1_.company_id AS company_4_7_1_,product1_.importer_id AS importer5_7_1_,product1_.name AS name3_7_1_ FROM image image0_ INNER JOIN product product1_ ON image0_.product_id = product1_.id WHERE product1_.id = ?

我還需要添加一件事，這與WarehouseProductInfo的@oneToOne關系有關。 對于可選的@OnetoOne關聯，將忽略LAZY屬性，因為Hiberante必須知道它是否必須使用null或代理來填充您的Entity。 在我們的示例中，將其強制性是有意義的，因為每種產品無論如何都位于倉庫中。 在其他情況下，您可以簡單地使關聯成為單向的，并僅保留控制鏈接的部分（外鍵所在的部分）。

• 代碼可在GitHub上獲得 。

參考： Hibernate Facts：從JCG合作伙伴 Vlad Mihalcea的Vlad Mihalcea博客博客中獲取策略的重要性 。

翻譯自: https://www.javacodegeeks.com/2013/11/hibernate-facts-the-importance-of-fetch-strategy.html

非一致性訪存系統

總結

以上是生活随笔為你收集整理的非一致性访存系统_Hibernate事实：访存策略的重要性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。