jpa序列ID生成

Question

通過在將實體持久保存到數據庫之前將ID分配給實體來獲得巨大的價值，但是在構造函數中立即執行：您的equals / hashcode實現變得微不足道， 並且它可以節省許多麻煩 。

當實體等式基於==時，我已經看到了問題：代理進入會話，當它作為真實對象被解包時，你得到返回false equals() 。

當你重寫equals和hashcode以使用生成的ID時，因為那個只在persist()上生成，所有非持久化實體都具有id null ，因此它們彼此相等。

從我讀到的內容來看，當你使用傳統的ID生成技術時（比如說自動增量），在刷新實體管理器時會生成ID。 當您使用基於序列的解決方案時，它會在持續時間生成。

那篇文章和我目前的理解說最簡單的解決方案是在創建時分配ID，而不是持久或刷新時間。 並且序列似乎可以到達，但JPA決定反對它。 通過序列獲取ID是便宜的（因為你可以預取），為什么JPA至少沒有提供在對象構建時獲得基於序列的ID的選項？ 如果實體最終沒有持久存在，則存在浪費一些ID的風險，但我認為這不是一個大問題。

除此之外，就解決方案的簡單性和可理解性而言，唯一的“不妥協”似乎是UUID，它們都有自己的問題。

我錯過了什么嗎？ 是否有某些JPA身份生成器或某些庫將基於序列並允許在構建時提供ID？

Answer 1

從寫作的角度來看，使用指定的標識符是最好的方法。 它在所有實體狀態轉換中也是一致的，您甚至可以在JDBC級別批量多個插入。

在閱讀和索引方面，數字列表現更好，分配的標識符是唯一的邏輯密鑰（社會安全號碼）或唯一標識符（例如UUID）。 使用應用程序級唯一分配的標識符很復雜，因為您可能有多個應用程序節點（在群集中），或者您希望在應用程序內部以及從外部源（數據庫客戶端實用程序）同步插入。

對於數據庫分配的標識符，您需要考慮如何根據您的選擇影響刷新。 Hibernate試圖將持久性上下文推遲到最后一刻 。 這種策略傳統上稱為事務性后寫。

后寫與Hibernate刷新更相關，而不是任何邏輯或物理事務。 在交易期間，可以多次發生沖洗。

刷新的更改僅對當前數據庫事務可見。 在提交當前事務之前，其他並發事務不會看到任何更改。

IDENTITY需要刷新 ，而序列是非事務性的，因此它不需要刷新。 IDENTITY禁用JDBC插入批處理，它不支持預分配。

JPA無法在Entity構造時分配標識符，因為新實例只能通過EntityManager.persist（）調用保持持久化。 JPA需要明確的“實體狀態轉換”。

浪費序列標識符不是什么大問題。 即使序列值存在間隙，數據庫也能正常運行。 使用bigint列可以保證您實際上不會用盡序列標識符。 具有偶然間隙的非事務性序列標識符分配比具有較高死鎖爭用風險的事務分配更好。