JPA hashCode () / eşittir () ikilemi

Olmuştur bazı tartışmalar JPA varlıkları ve yaklaşık burada hashCode()/ equals()JPA varlık sınıfları için kullanılmalıdır uygulanması. Bunların çoğu (hepsi değilse de) Hazırda Bekleme'ye bağlıdır, ancak bunları JPA-uygulama-tarafsız olarak tartışmak istiyorum (bu arada EclipseLink kullanıyorum).

Tüm olası uygulamaların kendi avantaj ve dezavantajları vardır :

• hashCode()/equals() Sözleşme uygunluk için (değişmezlik) List/ Setoperasyonlar
• İster aynı nesneler (örneğin, farklı oturumlar lazily yüklenmiş veri yapılarının dinamik proxy) tespit edilebilir
• Varlıkların bağımsız (veya kalıcı olmayan) durumda doğru davranıp davranmadığı
  

Görebildiğim kadarıyla üç seçenek var :

1. Onları geçersiz kılmayın; güven Object.equals()veObject.hashCode()
   • hashCode()/ equals()iş
   • özdeş nesneleri, dinamik proxy'lerle ilgili sorunları tanımlayamıyor
   • müstakil varlıklarla sorun yok
2. Birincil anahtara göre bunları geçersiz kılın
   • hashCode()/ equals()bozuk
   • doğru kimlik (tüm yönetilen varlıklar için)
   • müstakil varlıklarla ilgili sorunlar
3. Business-ID'ye (birincil olmayan anahtar alanları; yabancı anahtarlar ne olacak?) Dayalı olarak bunları geçersiz kılın.
   • hashCode()/ equals()bozuk
   • doğru kimlik (tüm yönetilen varlıklar için)
   • müstakil varlıklarla sorun yok

Sorularım:

1. Bir seçeneği ve / veya pro / con noktasını kaçırdım mı?
   
2. Hangi seçeneği seçtiniz ve neden?

GÜNCELLEME 1:

"By hashCode()/ equals()kırılır", bunu izleyen demek hashCode()(doğru bir şekilde uygulandığında zaman) anlamında kırık olmadığı, farklı değerleri döndürebilir çağırmaları ObjectAPI belgeleri, ama bir de değişmiş varlık almaya çalışırken hangi sorunlara neden olmaktadır Map, Setya da diğer karma tabanlı Collection. Sonuç olarak, JPA uygulamaları (en azından EclipseLink) bazı durumlarda düzgün çalışmayacaktır.

GÜNCELLEME 2:

Yanıtlarınız için teşekkür ederiz - çoğu dikkate değer bir kaliteye sahiptir.
Ne yazık ki, gerçek bir uygulama için hangi yaklaşımın en iyi olacağından veya başvurum için en iyi yaklaşımın nasıl belirleneceğinden hala emin değilim. Bu yüzden, soruyu açık tutacağım ve daha fazla tartışma ve / veya görüş umuyorum.

Konuyla ilgili bu çok güzel makaleyi okuyun: Hazırda Bekletme Kimliğinizi Çalmasına İzin Verme .

Makalenin sonucu şöyle:

Nesneler bir veritabanında kalmaya devam ettiğinde, nesne kimliğinin doğru bir şekilde uygulanması zordur. Ancak, sorunlar tamamen nesnelerin kaydedilmeden önce kimlik olmadan var olmasına izin vermekten kaynaklanır. Bu sorunları, nesne kimlikleri Hazırda Bekleme gibi nesne ilişkisel eşleme çerçevelerinden ayırma sorumluluğunu alarak çözebiliriz. Bunun yerine, nesne başlatıldığında nesne kimlikleri atanabilir. Bu, nesne kimliğini basit ve hatasız hale getirir ve etki alanı modelinde gereken kod miktarını azaltır.

Her zaman eşittir / karma kodunu geçersiz kılar ve iş kimliğine göre uygularım. Benim için en makul çözüm gibi görünüyor. Aşağıdaki bağlantıya bakın .

Tüm bunları özetlemek için, eşittir / hashCode'u işlemek için farklı yollarla neyin işe yarayıp neyin işe yaramayacağını gösteren bir liste:

DÜZENLE :

Bunun benim için neden işe yaradığını açıklamak için:

1. JPA uygulamamda genellikle karma tabanlı koleksiyonu (HashMap / HashSet) kullanmıyorum. Gerekirse, UniqueList çözümü oluşturmayı tercih ederim.
2. Çalışma zamanında iş kimliğini değiştirmek herhangi bir veritabanı uygulaması için en iyi uygulama olmadığını düşünüyorum. Başka bir çözümün bulunmadığı nadir durumlarda, elemanı çıkarmak ve hashed tabanlı koleksiyona geri koymak gibi özel tedavi yaparım.
3. Modelim için, iş kimliğini yapıcıya ayarladım ve bunun için ayarlayıcı sağlamıyorum. JPA uygulamasının özellik yerine alanı değiştirmesine izin verdim .
4. UUID çözümü aşırıya kaçmış gibi görünüyor. Doğal işletme kimliğiniz varsa neden UUID? Sonuçta veritabanında iş kimliğinin benzersizliğini ayarlar. Neden veritabanındaki her tablo için ÜÇ dizin var?

Varlıklarımızda genellikle iki kimliğimiz vardır:

1. Sadece kalıcılık katmanı içindir (böylece kalıcılık sağlayıcısı ve veritabanı nesneler arasındaki ilişkileri anlayabilir).
2. Uygulama ihtiyaçlarımız için ( equals()ve hashCode()özellikle)

Bir göz at:

@Entity
public class User {

    @Id
    private int id;  // Persistence ID
    private UUID uuid; // Business ID

    // assuming all fields are subject to change
    // If we forbid users change their email or screenName we can use these
    // fields for business ID instead, but generally that's not the case
    private String screenName;
    private String email;

    // I don't put UUID generation in constructor for performance reasons. 
    // I call setUuid() when I create a new entity
    public User() {
    }

    // This method is only called when a brand new entity is added to 
    // persistence context - I add it as a safety net only but it might work 
    // for you. In some cases (say, when I add this entity to some set before 
    // calling em.persist()) setting a UUID might be too late. If I get a log 
    // output it means that I forgot to call setUuid() somewhere.
    @PrePersist
    public void ensureUuid() {
        if (getUuid() == null) {
            log.warn(format("User's UUID wasn't set on time. " 
                + "uuid: %s, name: %s, email: %s",
                getUuid(), getScreenName(), getEmail()));
            setUuid(UUID.randomUUID());
        }
    }

    // equals() and hashCode() rely on non-changing data only. Thus we 
    // guarantee that no matter how field values are changed we won't 
    // lose our entity in hash-based Sets.
    @Override
    public int hashCode() {
        return getUuid().hashCode();
    }

    // Note that I don't use direct field access inside my entity classes and
    // call getters instead. That's because Persistence provider (PP) might
    // want to load entity data lazily. And I don't use 
    //    this.getClass() == other.getClass() 
    // for the same reason. In order to support laziness PP might need to wrap
    // my entity object in some kind of proxy, i.e. subclassing it.
    @Override
    public boolean equals(final Object obj) {
        if (this == obj)
            return true;
        if (!(obj instanceof User))
            return false;
        return getUuid().equals(((User) obj).getUuid());
    }

    // Getters and setters follow
}

EDIT:setUuid() yöntem çağrıları ile ilgili benim noktaya açıklık getirmek . İşte tipik bir senaryo:

User user = new User();
// user.setUuid(UUID.randomUUID()); // I should have called it here
user.setName("Master Yoda");
user.setEmail("yoda@jedicouncil.org");

jediSet.add(user); // here's bug - we forgot to set UUID and 
                   //we won't find Yoda in Jedi set

em.persist(user); // ensureUuid() was called and printed the log for me.

jediCouncilSet.add(user); // Ok, we got a UUID now

Testlerimi çalıştırıp günlük çıktısını gördüğümde sorunu çözdüm:

User user = new User();
user.setUuid(UUID.randomUUID());

Alternatif olarak, ayrı bir yapıcı sağlanabilir:

@Entity
public class User {

    @Id
    private int id;  // Persistence ID
    private UUID uuid; // Business ID

    ... // fields

    // Constructor for Persistence provider to use
    public User() {
    }

    // Constructor I use when creating new entities
    public User(UUID uuid) {
        setUuid(uuid);
    }

    ... // rest of the entity.
}

Yani benim örneğim şöyle görünecekti:

User user = new User(UUID.randomUUID());
...
jediSet.add(user); // no bug this time

em.persist(user); // and no log output

Varsayılan bir kurucu ve bir ayarlayıcı kullanıyorum, ancak iki kurucu yaklaşımını sizin için daha uygun bulabilirsiniz.

Şahsen bu üç durumun hepsini farklı projelerde kullandım. Ve seçenek 1'in gerçek hayat uygulamasında en pratik olduğunu söylemek gerekir. Deneyimlerime göre, hashCode () / equals () uyumluluğunu kırmak, bir koleksiyona bir varlık eklendikten sonra eşitlik sonucunun değiştiği durumlarda her zaman sona ereceği gibi birçok çılgın hataya yol açar.

Ancak başka seçenekler de var (artıları ve eksileri ile):

a) hashCode / kümesi dayalı eşittir değişmez , değil boş , atanan yapıcı , alanlar

(+) her üç kriter de garanti altına alınmıştır

(-) alan değerleri yeni bir örnek oluşturmak için kullanılabilir olmalıdır

(-) eğer birini değiştirmek zorunda kalırsanız kullanımı zorlaştırır

b) hashCode /, uygulama tarafından JPA yerine (yapıcıda) atanan birincil anahtara eşittir

(+) her üç kriter de garanti altına alınmıştır

(-) DB dizileri gibi basit güvenilir kimlik oluşturma durumlarından yararlanamazsınız

(-) dağıtılmış bir ortamda (istemci / sunucu) veya uygulama sunucusu kümesinde yeni varlıklar oluşturulursa karmaşık

c) hashCode / varlığın kurucusu tarafından atanan bir UUID'ye eşittir

(+) her üç kriter de garanti altına alınmıştır

(-) UUID üretim yükü

(-) kullanılan algoritmaya bağlı olarak aynı UUID'nin iki katının kullanılması riski olabilir (DB'deki benzersiz bir dizin tarafından algılanabilir)

equals()/hashCode()Kümeleriniz için kullanmak istiyorsanız , aynı varlığın sadece bir kez orada olabilmesi açısından, tek bir seçenek vardır: Seçenek 2. Bunun nedeni , bir varlığın birincil anahtarının tanımı gereği asla değişmemesidir (eğer biri gerçekten güncellenirse) artık aynı varlık değil)

Bunu tam anlamıyla almalısınız: equals()/hashCode()Birincil anahtarı temel aldığınızdan, birincil anahtar ayarlanana kadar bu yöntemleri kullanmamalısınız. Dolayısıyla, birincil anahtar atanana kadar varlıkları kümeye koymamalısınız. (Evet, UUID'ler ve benzer kavramlar birincil anahtarları erkenden atamanıza yardımcı olabilir.)

Şimdi, "iş anahtarları" olarak adlandırılabilecek kötü bir dezavantaja sahip olsa da, Seçenek 3 ile bunu başarmak teorik olarak da mümkündür: "Tek yapmanız gereken önceden eklenen varlıkları setten silmek ( ekleyin) ve yeniden takın. " Bu doğrudur - ama aynı zamanda, dağıtılmış bir sistemde, verilerin kesinlikle eklendiği her yerde yapıldığından emin olmanız gerektiği anlamına gelir (ve güncellemenin gerçekleştirildiğinden emin olmanız gerekir) , başka şeyler gerçekleşmeden önce). Özellikle bazı uzak sistemlere şu anda ulaşılamıyorsa, gelişmiş bir güncelleme mekanizmasına ihtiyacınız olacaktır ...

Seçenek 1 yalnızca, kümelerinizdeki tüm nesneler aynı Hazırda Bekletme oturumundaysa kullanılabilir. Hazırda Bekletme belgeleri, 13.1.3 bölümünde bunu açıkça ortaya koymaktadır . Nesne kimliği göz önüne alındığında :

Bir Oturum içinde uygulama, nesneleri karşılaştırmak için güvenli bir şekilde == kullanabilir.

Ancak, Oturum dışında == kullanan bir uygulama beklenmedik sonuçlar doğurabilir. Bu, bazı beklenmedik yerlerde bile ortaya çıkabilir. Örneğin, aynı Kümeye iki bağımsız örnek koyarsanız, her ikisi de aynı veritabanı kimliğine sahip olabilir (yani, aynı satırı temsil eder). Bununla birlikte, JVM kimliği, tanımı gereği, bağımsız bir durumdaki örnekler için garanti edilmez. Geliştirici, kalıcı sınıflarda equals () ve hashCode () yöntemlerini geçersiz kılmalı ve kendi nesne eşitliği kavramını uygulamalıdır.

3. Seçenek lehine tartışmaya devam etmektedir:

Bir uyarı var: Eşitliği uygulamak için asla veritabanı tanımlayıcısını kullanmayın. Benzersiz, genellikle değişmez özelliklerin birleşiminden oluşan bir işletme anahtarı kullanın. Geçici bir nesne kalıcı hale getirilirse veritabanı tanımlayıcısı değişecektir. Geçici örnek (genellikle ayrı örneklerle birlikte) bir Kümede tutulursa, karma kodun değiştirilmesi Kümenin sözleşmesini bozar.

Bu doğrudur, eğer sizin

• kimliği erken atayamazsınız (örneğin UUID'leri kullanarak)
• ve yine de nesnelerini geçici durumdayken setlere koymak istersiniz.

Aksi takdirde, Seçenek 2'yi seçmekte özgürsünüz.

Sonra göreceli bir istikrar ihtiyacından bahsediyor:

İş anahtarları için özniteliklerin veritabanı birincil anahtarları kadar kararlı olması gerekmez; yalnızca nesneler aynı Sette olduğu sürece istikrarı garanti etmeniz gerekir.

Doğru. Bununla ilgili gördüğüm pratik sorun: Eğer mutlak istikrarı garanti edemezseniz, "nesneler aynı Sette olduğu sürece" istikrarı nasıl garanti edersiniz? Bazı özel durumları hayal edebiliyorum (setleri sadece bir konuşma için kullanmak ve sonra atmak gibi), ancak bunun genel uygulanabilirliğini sorgulayacağım.

Kısa versiyon:

• Seçenek 1 yalnızca tek bir oturumdaki nesnelerle kullanılabilir.
• Mümkünse Seçenek 2'yi kullanın. (PK atanana kadar kümelerdeki nesneleri kullanamayacağınız için mümkün olduğunca erken PK atayın.)
• Göreceli kararlılığı garanti edebiliyorsanız Seçenek 3'ü kullanabilirsiniz. Ancak buna dikkat edin.

1. Bir iş anahtarınız varsa , equals/ için bunu kullanmalısınız hashCode.
2. Bir iş anahtarınız yoksa, Objectsiz mergeve varlıktan sonra çalışmadığı için varsayılan eşitler ve hashCode uygulamalarıyla bırakmamalısınız .

3. Sen olabilir bu yazı önerildiği üzere varlık tanımlayıcı kullanmak . Tek yakalama, hashCodeher zaman aynı değeri döndüren bir uygulama kullanmanız gerektiğidir , örneğin:

   @Entity
   public class Book implements Identifiable<Long> {
   
       @Id
       @GeneratedValue
       private Long id;
   
       private String title;
   
       @Override
       public boolean equals(Object o) {
           if (this == o) return true;
           if (!(o instanceof Book)) return false;
           Book book = (Book) o;
           return getId() != null && Objects.equals(getId(), book.getId());
       }
   
       @Override
       public int hashCode() {
           return 31;
       }
   
       //Getters and setters omitted for brevity
   }

Her ne kadar bir iş anahtarı kullanmak (seçenek 3) en çok önerilen yaklaşım olsa da ( Hazırda Bekleme topluluk wiki'si , "Hazırda Bekletme ile Java Kalıcılığı" s. 398) ve bu çoğunlukla en çok kullandığımız şeydir, bunu hevesli bir şekilde ihlal eden bir Hazırda Bekletme hatası vardır. kümeleri: HHH-3799 . Bu durumda, Hazırda Beklet, alanları başlatılmadan önce bir kümeye varlık ekleyebilir. Bu hatanın neden daha fazla dikkat çekmediğinden emin değilim, çünkü önerilen iş anahtarı yaklaşımını gerçekten sorunlu hale getiriyor.

Meselenin kalbi, eşittir ve hashCode'un değişmez duruma (referans Odersky ve ark. ) Dayandırılması ve Hazırda Bekletme tarafından yönetilen birincil anahtarı olan bir Hazırda Bekletme varlığının böyle bir değişmez durumu olmamasıdır . Geçici bir nesne kalıcı hale geldiğinde birincil anahtar Hazırda Bekletme tarafından değiştirilir. İş anahtarı, başlatma işlemindeki bir nesneyi nemlendirdiğinde Hazırda Bekletme tarafından da değiştirilir.

Bu, yalnızca nesne 1'i bırakır, java.lang.Object uygulamalarını nesne kimliğine dayalı olarak veya James Brundege tarafından "Hazırda Bekletme Kimliğinizi Çalmasına İzin Verme " (zaten Stijn Geukens'in cevabına referansta bulunma) ) ve "Nesne Üretimi: Hazırda Bekletme Entegrasyonuna Daha İyi Bir Yaklaşım" da Lance Arlaus tarafından yapılmıştır .

Seçenek 1 ile ilgili en büyük sorun, ayrılmış örneklerin .equals () kullanan kalıcı örneklerle karşılaştırılamamasıdır. Ama sorun değil; eşittir ve hashCode sözleşmesi, her sınıf için eşitliğin ne anlama geldiğine karar vermek için geliştiriciye bırakır. Sadece equals ve hashCode nesnelerini devralsın. Ayrılmış bir örneği kalıcı bir örnekle karşılaştırmanız gerekiyorsa, bu amaç için açık bir şekilde yeni bir yöntem boolean sameEntityveya belki de boolean dbEquivalentveya boolean businessEquals.

Andrew'un cevabına katılıyorum. Uygulamamızda da aynı şeyi yapıyoruz, ancak UUID'leri VARCHAR / CHAR olarak depolamak yerine, onu iki uzun değere ayırıyoruz. Bkz. UUID.getLeastSignificantBits () ve UUID.getMostSignificantBits ().

Dikkate alınması gereken bir şey daha, UUID.randomUUID () çağrılarının oldukça yavaş olmasıdır, bu nedenle UUID'yi yalnızca gerektiğinde tembel olarak oluşturmak veya kalıcılık veya equals () / hashCode () çağrıları gibi bakmak isteyebilirsiniz.

@MappedSuperclass
public abstract class AbstractJpaEntity extends AbstractMutable implements Identifiable, Modifiable {

    private static final long   serialVersionUID    = 1L;

    @Version
    @Column(name = "version", nullable = false)
    private int                 version             = 0;

    @Column(name = "uuid_least_sig_bits")
    private long                uuidLeastSigBits    = 0;

    @Column(name = "uuid_most_sig_bits")
    private long                uuidMostSigBits     = 0;

    private transient int       hashCode            = 0;

    public AbstractJpaEntity() {
        //
    }

    public abstract Integer getId();

    public abstract void setId(final Integer id);

    public boolean isPersisted() {
        return getId() != null;
    }

    public int getVersion() {
        return version;
    }

    //calling UUID.randomUUID() is pretty expensive, 
    //so this is to lazily initialize uuid bits.
    private void initUUID() {
        final UUID uuid = UUID.randomUUID();
        uuidLeastSigBits = uuid.getLeastSignificantBits();
        uuidMostSigBits = uuid.getMostSignificantBits();
    }

    public long getUuidLeastSigBits() {
        //its safe to assume uuidMostSigBits of a valid UUID is never zero
        if (uuidMostSigBits == 0) {
            initUUID();
        }
        return uuidLeastSigBits;
    }

    public long getUuidMostSigBits() {
        //its safe to assume uuidMostSigBits of a valid UUID is never zero
        if (uuidMostSigBits == 0) {
            initUUID();
        }
        return uuidMostSigBits;
    }

    public UUID getUuid() {
        return new UUID(getUuidMostSigBits(), getUuidLeastSigBits());
    }

    @Override
    public int hashCode() {
        if (hashCode == 0) {
            hashCode = (int) (getUuidMostSigBits() >> 32 ^ getUuidMostSigBits() ^ getUuidLeastSigBits() >> 32 ^ getUuidLeastSigBits());
        }
        return hashCode;
    }

    @Override
    public boolean equals(final Object obj) {
        if (obj == null) {
            return false;
        }
        if (!(obj instanceof AbstractJpaEntity)) {
            return false;
        }
        //UUID guarantees a pretty good uniqueness factor across distributed systems, so we can safely
        //dismiss getClass().equals(obj.getClass()) here since the chance of two different objects (even 
        //if they have different types) having the same UUID is astronomical
        final AbstractJpaEntity entity = (AbstractJpaEntity) obj;
        return getUuidMostSigBits() == entity.getUuidMostSigBits() && getUuidLeastSigBits() == entity.getUuidLeastSigBits();
    }

    @PrePersist
    public void prePersist() {
        // make sure the uuid is set before persisting
        getUuidLeastSigBits();
    }

}

Benden daha akıllıca işaret ettiği diğer insanlar gibi, orada çok sayıda strateji var. Yine de, uygulanan tasarım modellerinin çoğunun başarıya giden yolu kesmeye çalıştığı görülmektedir. Uzman inşaatçılar ve fabrika yöntemleri ile kurucu çağrılarını tamamen engellemiyorlarsa, kurucu erişimini sınırlarlar. Gerçekten de, açık bir API ile her zaman hoştur. Ancak tek neden, eşit ve karma kod geçersiz kılmalarını uygulama ile uyumlu hale getirmekse, bu stratejilerin KISS (Keep It Simple Aptal) ile uyumlu olup olmadığını merak ediyorum.

Benim için, kimliği inceleyerek eşitleri ve hashcode'u geçersiz kılmak istiyorum. Bu yöntemlerde, kimliğin boş olmamasını ve bu davranışı iyi belgelemesini istiyorum. Böylece onu başka bir yerde saklamadan önce yeni bir varlığın devam etmesi geliştiricilerin sözleşmesi haline gelecektir. Bu sözleşmeyi yerine getirmeyen bir başvuru bir dakika içinde başarısız olacaktır (umarım).

Dikkatli olun: Varlıklarınız farklı tablolarda depolanıyorsa ve sağlayıcınız birincil anahtar için bir otomatik oluşturma stratejisi kullanıyorsa, varlık türleri arasında çoğaltılmış birincil anahtarlar alırsınız. Böyle bir durumda, çalışma zamanı türlerini Object # getClass () çağrısıyla da elbette ki iki farklı türün eşit kabul edilmesini imkansız kılacaktır. Bu bana çok yakışıyor.

Burada zaten çok bilgilendirici cevaplar var ama size ne yaptığımızı anlatacağım.

Hiçbir şey yapmıyoruz (geçersiz kılma).

Koleksiyonlarda çalışmak için eşittir / karma koduna ihtiyacımız olursa, UUID kullanırız. Sadece yapıcıda UUID oluşturun. UUID için http://wiki.fasterxml.com/JugHome kullanıyoruz . UUID biraz daha pahalı bir CPU zekasıdır, ancak serileştirme ve db erişimine kıyasla ucuzdur.

Geçmişte her zaman 1. seçeneği kullandım çünkü bu tartışmaların farkındaydım ve yapılacak doğru şeyi bilinceye kadar hiçbir şey yapmamanın daha iyi olacağını düşündüm. Bu sistemlerin hepsi hala başarılı bir şekilde çalışıyor.

Ancak, bir dahaki sefere ben seçenek 2 deneyebilirsiniz - oluşturulan veritabanı kimliği kullanarak.

Kimlik ayarlanmamışsa Hashcode ve equals, IllegalStateException özel durumunu atar.

Bu, kaydedilmemiş varlıkları içeren küçük hataların beklenmedik şekilde görünmesini engelleyecektir.

İnsanlar bu yaklaşım hakkında ne düşünüyor?

İş anahtarları yaklaşımı bizim için uygun değil. İkilemi çözmek için DB tarafından oluşturulan kimlik , geçici geçici tempId kullanıyoruz ve eşit () / hashcode () geçersiz kılınıyoruz . Tüm varlıklar Varlığın torunlarıdır. Artıları:

1. DB'de fazladan alan yok
2. Torun varlıklarında fazladan kodlama yok, herkes için bir yaklaşım
3. Performans sorunu yok (UUID gibi), DB Kimliği oluşturma
4. Hashmaps ile ilgili bir sorun yok (eşit vb. Kullanımını aklınızda bulundurmanıza gerek yok)
5. Yeni varlığın karma kodu, devam ettikten sonra bile zaman içinde değişmedi

Eksileri:

1. Kalıcı olmayan varlıkların serileştirilmesi ve serileştirilmesi ile ilgili sorunlar olabilir
2. Kaydedilen varlığın karma kodu DB'den yeniden yüklendikten sonra değişebilir
3. Kalıcı olmayan nesneler her zaman farklı kabul edilir (belki de bu doğru mu?)
4. Başka?

Kodumuza bakın:

@MappedSuperclass
abstract public class Entity implements Serializable {

    @Id
    @GeneratedValue
    @Column(nullable = false, updatable = false)
    protected Long id;

    @Transient
    private Long tempId;

    public void setId(Long id) {
        this.id = id;
    }

    public Long getId() {
        return id;
    }

    private void setTempId(Long tempId) {
        this.tempId = tempId;
    }

    // Fix Id on first call from equal() or hashCode()
    private Long getTempId() {
        if (tempId == null)
            // if we have id already, use it, else use 0
            setTempId(getId() == null ? 0 : getId());
        return tempId;
    }

    @Override
    public boolean equals(Object obj) {
        if (super.equals(obj))
            return true;
        // take proxied object into account
        if (obj == null || !Hibernate.getClass(obj).equals(this.getClass()))
            return false;
        Entity o = (Entity) obj;
        return getTempId() != 0 && o.getTempId() != 0 && getTempId().equals(o.getTempId());
    }

    // hash doesn't change in time
    @Override
    public int hashCode() {
        return getTempId() == 0 ? super.hashCode() : getTempId().hashCode();
    }
}

Lütfen önceden tanımlanmış tür tanımlayıcısına ve kimliğe dayalı olarak aşağıdaki yaklaşımı göz önünde bulundurun.

JPA için özel varsayımlar:

• aynı "tip" ve aynı null olmayan kimliğe sahip varlıklar eşit kabul edilir
• ısrarcı olmayan varlıklar (kimlik olmadığı varsayılarak) asla diğer varlıklara eşit değildir

Soyut varlık:

@MappedSuperclass
public abstract class AbstractPersistable<K extends Serializable> {

  @Id @GeneratedValue
  private K id;

  @Transient
  private final String kind;

  public AbstractPersistable(final String kind) {
    this.kind = requireNonNull(kind, "Entity kind cannot be null");
  }

  @Override
  public final boolean equals(final Object obj) {
    if (this == obj) return true;
    if (!(obj instanceof AbstractPersistable)) return false;
    final AbstractPersistable<?> that = (AbstractPersistable<?>) obj;
    return null != this.id
        && Objects.equals(this.id, that.id)
        && Objects.equals(this.kind, that.kind);
  }

  @Override
  public final int hashCode() {
    return Objects.hash(kind, id);
  }

  public K getId() {
    return id;
  }

  protected void setId(final K id) {
    this.id = id;
  }
}

Somut varlık örneği:

static class Foo extends AbstractPersistable<Long> {
  public Foo() {
    super("Foo");
  }
}

Test örneği:

@Test
public void test_EqualsAndHashcode_GivenSubclass() {
  // Check contract
  EqualsVerifier.forClass(Foo.class)
    .suppress(Warning.NONFINAL_FIELDS, Warning.TRANSIENT_FIELDS)
    .withOnlyTheseFields("id", "kind")
    .withNonnullFields("id", "kind")
    .verify();
  // Ensure new objects are not equal
  assertNotEquals(new Foo(), new Foo());
}

Buradaki ana avantajlar:

• basitlik
• alt sınıfların tip kimliği sağlamasını sağlar
• yakın sınıflarla öngörülen davranış

Dezavantajları:

• Her varlığın aranmasını gerektirir super()

Notlar:

• Kalıtım kullanılırken dikkat edilmesi gerekir. Örneğin , uygulamanın eşitliği class Ave class B extends Asomut ayrıntılarına bağlı olabilir.
• İdeal olarak, kimlik olarak bir işletme anahtarı kullanın

Yorumlarınızı dört gözle bekliyoruz.

Bu, Java ve JPA kullanan her BT sisteminde yaygın bir sorundur. Acı noktası eşittir () ve hashCode () uygulamalarının ötesine uzanır, bir kuruluşun bir kuruma nasıl başvurduğunu ve müşterilerinin aynı kuruma nasıl başvurduğunu etkiler. Görüşümü ifade etmek için kendi blogumu yazdığım noktaya bir iş anahtarına sahip olmamak için yeterince acı gördüm .

Kısacası: RAM dışındaki herhangi bir depolama birimine bağımlı olmadan oluşturulan iş anahtarı olarak anlamlı önekleri olan kısa, insan tarafından okunabilen sıralı bir kimlik kullanın. Twitter'ın Kar Tanesi buna çok iyi bir örnek.

IMO eşittir / hashCode uygulamak için 3 seçeneğiniz var

• Uygulama tarafından oluşturulan bir kimlik kullanın, yani bir UUID
• Bir iş anahtarına dayalı olarak uygulayın
• Birincil anahtara göre uygulayın

Uygulama tarafından oluşturulan bir kimlik kullanmak en kolay yaklaşımdır, ancak birkaç dezavantajı vardır

• PK olarak kullanıldığında birleştirmeler daha yavaştır, çünkü 128 Bit 32 veya 64 Bit'ten daha büyüktür
• "Hata ayıklama daha zor" çünkü bazı verilerin doğru olup olmadığını kendi gözlerinizle kontrol etmek oldukça zor

Bu dezavantajlarla çalışabiliyorsanız , sadece bu yaklaşımı kullanın.

Birleştirme sorununun üstesinden gelmek için, UUID doğal anahtar ve sıra değeri birincil anahtar olarak kullanılıyor olabilir, ancak yine de, temelde katılmak isteyeceğinizden, kimlikleri katıştırılmış bileşimli alt varlıklarda eşit / hashCode uygulama sorunlarıyla karşılaşabilirsiniz. birincil anahtarda. Alt öğe kimliğinde doğal anahtarı ve üst öğeye başvurmak için birincil anahtarı kullanmak iyi bir uzlaşmadır.

@Entity class Parent {
  @Id @GeneratedValue Long id;
  @NaturalId UUID uuid;
  @OneToMany(mappedBy = "parent") Set<Child> children;
  // equals/hashCode based on uuid
}

@Entity class Child {
  @EmbeddedId ChildId id;
  @ManyToOne Parent parent;

  @Embeddable class ChildId {
    UUID parentUuid;
    UUID childUuid;
    // equals/hashCode based on parentUuid and childUuid
  }
  // equals/hashCode based on id
}

IMO, tüm olumsuzluklardan kaçınacağı ve aynı zamanda size, sistem içlerini göstermeden harici sistemlerle paylaşabileceğiniz bir değer (UUID) sunacağı için en temiz yaklaşımdır.

Bir kullanıcıdan hoş bir fikir olmasını bekliyorsanız, ancak birkaç dezavantajla birlikte gelirse, bir iş anahtarına dayalı olarak uygulayın.

Çoğu zaman bu iş anahtarı , kullanıcının sağladığı bir tür kod ve daha az sıklıkla çoklu özelliklerin bir bileşimi olacaktır.

• Değişken uzunluktaki metne dayalı birleştirme basitçe yavaş olduğundan birleşimler daha yavaştır. Bazı DBMS, anahtar belirli bir uzunluğu aşarsa dizin oluşturmada sorun yaşayabilir.
• Deneyimlerime göre, iş anahtarları, ona atıfta bulunan nesnelere basamaklı güncelleştirmeler gerektiren değiştirme eğilimindedir. Harici sistemler buna atıfta bulunursa bu mümkün değildir

IMO, yalnızca bir iş anahtarını uygulamamalı veya üzerinde çalışmamalısınız. Bu güzel bir eklenti yani kullanıcılar bu iş anahtarıyla hızlı bir şekilde arama yapabilir, ancak sistem işletim için ona güvenmemelidir.

Birincil anahtara bağlı olarak sorunları var, ama belki de çok önemli değil

Kimlikleri harici sisteme göstermeniz gerekiyorsa, önerdiğim UUID yaklaşımını kullanın. Bunu yapmazsanız, yine de UUID yaklaşımını kullanabilirsiniz, ancak bunu yapmak zorunda değilsiniz. Equals / hashCode içinde DBMS tarafından oluşturulan bir kimliği kullanma sorunu, nesnenin kimliği atamadan önce karma tabanlı koleksiyonlara eklenmiş olabileceği gerçeğinden kaynaklanmaktadır.

Bunu aşmanın en açık yolu, nesneyi, kimliği atamadan önce karma tabanlı koleksiyonlara eklemektir. Bunun her zaman mümkün olmadığını anlıyorum, çünkü kimliği zaten atamadan önce tekilleştirmeyi isteyebilirsiniz. Karma tabanlı koleksiyonları kullanmaya devam etmek için, kimliği atadıktan sonra koleksiyonları yeniden oluşturmanız yeterlidir.

Bunun gibi bir şey yapabilirsiniz:

@Entity class Parent {
  @Id @GeneratedValue Long id;
  @OneToMany(mappedBy = "parent") Set<Child> children;
  // equals/hashCode based on id
}

@Entity class Child {
  @EmbeddedId ChildId id;
  @ManyToOne Parent parent;

  @PrePersist void postPersist() {
    parent.children.remove(this);
  }
  @PostPersist void postPersist() {
    parent.children.add(this);
  }

  @Embeddable class ChildId {
    Long parentId;
    @GeneratedValue Long childId;
    // equals/hashCode based on parentId and childId
  }
  // equals/hashCode based on id
}

Tam yaklaşımı kendim test etmedim, bu yüzden kalıcılık öncesi ve sonrası olaylarda koleksiyonları nasıl değiştirdiğinizden emin değilim ama fikir:

• Nesneyi karma tabanlı koleksiyonlardan geçici olarak kaldırın
• Devam et
• Nesneyi karma tabanlı koleksiyonlara yeniden ekleyin

Bunu çözmenin bir başka yolu, bir güncelleme / kalıcı işlemden sonra tüm karma tabanlı modellerinizi yeniden oluşturmaktır.

Sonunda, size kalmış. Şahsen sıra tabanlı yaklaşımı çoğu zaman kullanıyorum ve UUID yaklaşımını yalnızca bir tanımlayıcıyı harici sistemlere göstermem gerekirse kullanıyorum.

instanceofJava 14'ün yeni stili ile, equalsbir satırda uygulayabilirsiniz .

@Override
public boolean equals(Object obj) {
    return this == obj || id != null && obj instanceof User otherUser && id.equals(otherUser.id);
}

@Override
public int hashCode() {
    return 31;
}

UUID birçok insanın cevabıysa, neden sadece varlıkları oluşturmak ve oluşturma sırasında birincil anahtarı atamak için iş katmanından fabrika yöntemlerini kullanmıyoruz?

Örneğin:

@ManagedBean
public class MyCarFacade {
  public Car createCar(){
    Car car = new Car();
    em.persist(car);
    return car;
  }
}

bu şekilde varlık için kalıcılık sağlayıcısından varsayılan bir birincil anahtar alırdık ve hashCode () ve equals () fonksiyonlarımız buna güvenebilirdi.

Ayrıca Aracın inşaatçılarını korumalı ilan edebilir ve daha sonra bunlara erişmek için iş yöntemimizde yansımayı kullanabiliriz. Bu şekilde geliştiriciler Car'ı yeni bir şeyle örneklemek için değil, fabrika yöntemiyle niyet edeceklerdi.

Buna ne dersin?

Bu soruyu kendim cevaplamaya çalıştım ve bu yazıyı ve özellikle DREW olanı okuyana kadar bulunan çözümlerden asla tamamen memnun kalmadım. Tembel UUID yaratma ve onu en iyi şekilde saklama şeklini beğendim.

Ama daha fazla esneklik eklemek istedim, yani tembel SADECE hashCode () / equals () her çözümün avantajları ile varlığın ilk ısrarından önce erişildiğinde UUID oluşturmak:

• equals () "nesne aynı mantıksal varlığı ifade eder" anlamına gelir
• veritabanı kimliğini olabildiğince kullanın çünkü işi neden iki kez yapayım (performans sorunu)
• henüz var olmayan varlıkta hashCode () / equals () öğesine erişirken sorunu önleyin ve gerçekten devam ettikten sonra aynı davranışı koruyun

Aşağıdaki karışık çözümüm hakkındaki geri bildirimi gerçekten takdir ediyorum

public class MyEntity { 

    @Id()
    @Column(name = "ID", length = 20, nullable = false, unique = true)
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id = null;

    @Transient private UUID uuid = null;

    @Column(name = "UUID_MOST", nullable = true, unique = false, updatable = false)
    private Long uuidMostSignificantBits = null;
    @Column(name = "UUID_LEAST", nullable = true, unique = false, updatable = false)
    private Long uuidLeastSignificantBits = null;

    @Override
    public final int hashCode() {
        return this.getUuid().hashCode();
    }

    @Override
    public final boolean equals(Object toBeCompared) {
        if(this == toBeCompared) {
            return true;
        }
        if(toBeCompared == null) {
            return false;
        }
        if(!this.getClass().isInstance(toBeCompared)) {
            return false;
        }
        return this.getUuid().equals(((MyEntity)toBeCompared).getUuid());
    }

    public final UUID getUuid() {
        // UUID already accessed on this physical object
        if(this.uuid != null) {
            return this.uuid;
        }
        // UUID one day generated on this entity before it was persisted
        if(this.uuidMostSignificantBits != null) {
            this.uuid = new UUID(this.uuidMostSignificantBits, this.uuidLeastSignificantBits);
        // UUID never generated on this entity before it was persisted
        } else if(this.getId() != null) {
            this.uuid = new UUID(this.getId(), this.getId());
        // UUID never accessed on this not yet persisted entity
        } else {
            this.setUuid(UUID.randomUUID());
        }
        return this.uuid; 
    }

    private void setUuid(UUID uuid) {
        if(uuid == null) {
            return;
        }
        // For the one hypothetical case where generated UUID could colude with UUID build from IDs
        if(uuid.getMostSignificantBits() == uuid.getLeastSignificantBits()) {
            throw new Exception("UUID: " + this.getUuid() + " format is only for internal use");
        }
        this.uuidMostSignificantBits = uuid.getMostSignificantBits();
        this.uuidLeastSignificantBits = uuid.getLeastSignificantBits();
        this.uuid = uuid;
    }

Uygulamada, Seçenek 2'nin (Birincil anahtar) en sık kullanıldığı görülmektedir. Doğal ve TAŞINMAZ iş anahtarı nadiren bir şeydir, sentetik anahtarlar oluşturmak ve desteklemek, muhtemelen hiç gerçekleşmeyen durumları çözmek için çok ağırdır. Spring-data-jpa AbstractPersistable uygulamasına bir göz atın (tek şey: Hazırda Bekleme uygulaması kullanımı içinHibernate.getClass ).

public boolean equals(Object obj) {
    if (null == obj) {
        return false;
    }
    if (this == obj) {
        return true;
    }
    if (!getClass().equals(ClassUtils.getUserClass(obj))) {
        return false;
    }
    AbstractPersistable<?> that = (AbstractPersistable<?>) obj;
    return null == this.getId() ? false : this.getId().equals(that.getId());
}

@Override
public int hashCode() {
    int hashCode = 17;
    hashCode += null == getId() ? 0 : getId().hashCode() * 31;
    return hashCode;
}

Sadece HashSet / HashMap'te yeni nesneleri değiştirmenin farkında. Aksine, Seçenek 1 ( Objectuygulama devam ) hemen sonra kırılır merge, bu çok yaygın bir durumdur.

İş anahtarınız yoksa ve karma yapısında yeni bir varlığı manipüle etmek için GERÇEK bir gereksiniminiz varsa hashCode, aşağıda Vlad Mihalcea'nın önerildiği gibi sabit olarak geçersiz kılın .

Aşağıda Scala için basit (ve test edilmiş) bir çözüm bulunmaktadır.

• Bu çözümün, soruda verilen 3 kategoriden hiçbirine uymadığını unutmayın.

• Tüm Varlıklarım UUIDEntity'nin alt sınıflarıdır, bu yüzden tekrarlama (KURU) ilkesini izlerim.

• Gerekirse UUID üretimi daha hassas hale getirilebilir (daha fazla sahte rasgele sayılar kullanılarak).

Scala Kodu:

import javax.persistence._
import scala.util.Random

@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
abstract class UUIDEntity {
  @Id  @GeneratedValue(strategy = GenerationType.TABLE)
  var id:java.lang.Long=null
  var uuid:java.lang.Long=Random.nextLong()
  override def equals(o:Any):Boolean= 
    o match{
      case o : UUIDEntity => o.uuid==uuid
      case _ => false
    }
  override def hashCode() = uuid.hashCode()
}