Identité des objets Hibernate

Question

En Java, la persistance avec Hibernate gavin suggère que nous utilisions une clé professionnelle pour la comparaison d'égalité. Les clés professionnelles peuvent non seulement impliquer des comparaisons de champs multiples, mais il n'y a aucune garantie que la sémantique de la clé professionnelle "parfaite" ne changera pas à l'avenir. Nous vivons dans un monde non idéal et les exigences commerciales et les lois changent très fréquemment. Dans un tel cas, nous nous retrouverons avec des données dans la base de données stockées avec plusieurs sémantiques de clés métier. Je veux diviser le problème en deux parties :

1. Lorsque nous traitons strictement des objets persistants ou détachés.

2. Quand nous traitons des objets transitoires.

3. Je ne vois toujours pas d'inconvénient à utiliser une clé de substitution pour l'égalité et le code de hachage si nous traitons des objets persistants et détachés. Deux objets persistants ou détachés sont égaux s'ils ont la même clé primaire. Est-ce une erreur de supposer cela ?

4. Lorsque nous traitons des objets transitoires, nous pouvons utiliser la sémantique de la clé métier pour comparer les objets et disposer d'une stratégie de fusion si vous essayez de faire persister deux objets transitoires avec la même clé métier mais des valeurs différentes dans l'attribut remainder.

Dans les applications à lecture intensive, où la plupart des transactions sont des lectures/mises à jour, cette stratégie devrait donner de meilleures performances.

Answer 1

Le problème de l'identité des objets et d'Hibernate concerne les objets transitoires : quand la clé primaire est-elle créée ? Si la réponse est lorsque vous écrivez dans la BD (en utilisant une génération de clé primaire contrôlée par la BD, comme une séquence Oracle), alors vous avez un problème potentiel.

Si la clé primaire est utilisée comme base pour la vérification de l'égalité et qu'elle fait partie de la génération du code de hachage, vous briserez le contrat de code de hachage car l'objet ne sera pas le même avant et après la génération de la clé primaire.

Si vous le pouvez, utilisez simplement une clé primaire générée que vous pouvez définir au moment de la création de l'objet (comme un UUID). Cela garantit la cohérence du code de hachage et du contrôle d'égalité.

Answer 2

J'avais l'habitude de me tourmenter pour trouver la clé professionnelle parfaite pour chaque classe et je finissais par utiliser un UUID dans des situations où il n'y avait tout simplement rien d'unique qui ne pouvait jamais changer. Mais maintenant, j'utilise la clé de substitution de la base de données et j'évite les situations où je dois dépendre de l'égalité pour les objets transitoires. Cela me semble plus simple, moins sujet à des erreurs et plus rapide. Cela peut dépendre du type d'application, mais pour les applications CRUD typiques, l'objet est généralement placé dans la base de données avant que vous n'ayez à vous en occuper dans une collection.