Ich erstelle einen benutzerdefinierten UserType in Hibernate für ein Projekt. Es war relativ einfach, bis ich zu der isMutable-Methode kam. Ich versuche herauszufinden, was diese Methode vertraglich bedeutet.
Bedeutet das, dass die Klasse, für die ich den UserType erstelle, unveränderlich ist oder bedeutet das Objekt, das einen Verweis auf eine Instanz dieser Klasse enthält, niemals auf eine andere Instanz?
Ich habe ein paar Beispiele im Hibernate Community Wiki gefunden, wo sie wahr zurückkehrten, weil das Objekt selbst veränderbar war - Ссылка .
Andere Beispiele im Community-Wiki haben falsch zurückgegeben, ohne warum, obwohl sie auch änderbar waren.
Ich habe das JavaDoc überprüft, aber es ist auch nicht sehr klar.
Aus dem JavaDoc für UserType :
%Vor%Aus JavaDoc für Typ :
%Vor%Hibernate behandelt Typen, die als "veränderbar" gekennzeichnet sind, als könnten sie sich ändern (d. h. erfordern ein UPDATE) ohne auf eine neue Referenz zu zeigen. Wenn Sie einer Hibernate-geladenen Eigenschaft einen neuen Verweis zuweisen, erkennt Hibernate dies auch dann, wenn der Typ unveränderlich ist. Dies geschieht zum Beispiel bei String-Feldern. Aber wenn Sie beispielsweise ein StringBuilder-Feld haben und es als unveränderlich Hibernate markieren, wird nicht angezeigt, wenn Sie den StringBuilder ändern.
Siehe diesen Blogbeitrag für weitere Details und ein Beispielprojekt.
Das typische Beispiel hier ist die String-Klasse - sie ist unveränderlich, d. h. sobald die Zeichenkette erstellt wurde, können Sie ihren Inhalt oder Zustand nicht ändern, und wenn Sie das möchten, müssen Sie sie in eine neue Kopie verarbeiten.
isMutable returning true bedeutet, dass Sie sagen, dass der Zustand dieses Objekts von externen Objekten geändert werden kann. Wenn Sie false zurückgeben, bedeutet dies, dass Sie dieses Objekt in eine neue Instanz kopieren müssen, um die Änderungen zu bestätigen. Oder wie Sie sagten: "Bedeutet das, dass das Objekt, das eine Referenz auf eine Instanz dieser Klasse enthält, niemals auf eine andere Instanz zeigt".