pourquoi hibernate forcer la sérialisation dans la méthode session.get

Question

Je vois que les méthodes session.get() et load() d'hibernate n'acceptent que les objets Serializable. Selon ma compréhension d'hibernate, il générera une instruction SQL et l'enverra au SGBD. Il n'aura jamais besoin d'envoyer un objet Java sur le réseau.

Pourquoi hiberner nous impose-t-il une sérialisation?

Answer 1

Je pense que c'est à cause de la prise en charge de la mise en cache. Lorsque vous utilisez un cache permanent ou toute mise en cache qui distribue un objet via le réseau, vous devez vous assurer que les objets peuvent être transportés dans un format commun, en l'occurrence la sérialisation Java.

Answer 2

Je ne le vois franchement pas autrement. Si vous n'êtes pas la structure de table définissant et générant des instructions d'insertion pour accueillir des objets, l'instruction SQL générée est une chaîne en elle-même et elle insère une autre chaîne de texte (vos données sérialisées) dans un champ d'une table. Quoi que vous insériez dans une base de données doit être une chaîne dans ce cas, il ne peut pas être un objet avec des méthodes dépendantes du langage, sauf si vous concevez explicitement une table pour stocker des données comme ça.

Answer 3

Ce n'est pas tout à fait vrai. From the Javadoc, la signature des méthodes pertinentes est:

public Object get(Class clazz, Serializable id) ... 
public Object load(Class theClass, Serializable id) ... 

(pièces et autres versions surchargées non pertinentes omis par souci de concision). Ainsi, l'entité à charger peut appartenir à n'importe quelle classe, seul son identificateur doit être sérialisable.

Les entités en effet ne peuvent pas être sérialisables, selon cette citation de Java Persistence with Hibernate, ch. 13.3.2:

Les instances persistantes sont stockées dans le cache de second niveau sous une forme désassemblée . Pensez au désassemblage comme un processus un peu comme la sérialisation (l'algorithme est beaucoup, beaucoup plus rapide que la sérialisation Java, cependant).

Donc je suppose que les identifiants (dans le cache de requête) ne sont pas non plus sérialisés. Je ne pouvais pas trouver d'explication sur pourquoi id est déclaré Serializable, et manquant de cela, je ne peux que deviner. L'API a besoin d'un type pour le paramètre id, qui doit être un supertype commun d'au moins les types d'identificateur fréquemment utilisés Number et String, et à l'exception de Object, Serializable est le seul choix.

Answer 4

D'abord, le fait que Hibernate utilise Serializable dans une signature ne signifie pas que Hibernate va sérialisation quoi que ce soit, cela signifie simplement que les paramètres sont sérialisable si le besoin se fait sentir.

Ensuite, je ne pouvais pas trouver une référence absolue, mais je pense que l'argument le plus fort est:

• Les entités sont Ids utiliser comme clé pour la mise en cache (premier niveau, deuxième niveau) et peut être envoyer sur le fil

Certains arguments les plus faibles (ou non l'argument à tous):

• le Session lui-même peut être potentiellement sérialisé (par exemple pour être stockés dans le HttpSession)
• Hibernate a besoin d'un super type pour entityId (y compris PK composite)

Compte tenu de tout cela, je pense qu'il est logique d'appliquer les utilisateurs de l'API pour passer un Serializable entityId, ce qui permet de ne pas fermer une porte et pour éviter toute limitation ultérieure (oups, vous ne pouvez pas activer la mise en cache de second niveau car ce PK n'est pas Serializable). C'est IMO une décision de conception beaucoup mieux que d'utiliser Object. Et pour être honnête, je ne vois pas d'ennui avec ça.