bayt [] için uygun hazırda bekletme ek açıklaması

Hazırda bekletme 3.1 ve JPA açıklamalarını kullanan bir uygulamam var. Bayt [] özniteliklerine (1k - 200k boyutunda) sahip birkaç nesneye sahiptir. JPA @Lob açıklamasını kullanır ve hazırda bekletme 3.1, tüm büyük veritabanlarında bunları gayet iyi okuyabilir - JDBC Blob satıcı özelliklerini gizler gibi görünüyor (yapması gerektiği gibi).

@Entity
public class ConfigAttribute {
  @Lob
  public byte[] getValueBuffer() {
    return m_valueBuffer;
  }
}

Postgresql'de (geçici çözüm olmadan ) bu ek açıklama kombinasyonunu 3.5 kesintiyi hazırda beklettiğimizi (ve düzeltmeyeceğini) keşfettiğimizde 3.5'e yükseltmek zorunda kaldık . Şimdiye kadar net bir düzeltme bulamadım, ancak @Lob'u kaldırırsam postgresql türü baytını kullandığını fark ettim (bu işe yarıyor, ancak yalnızca postgreslerde).

annotation                   postgres     oracle      works on
-------------------------------------------------------------
byte[] + @Lob                oid          blob        oracle
byte[]                       bytea        raw(255)    postgresql
byte[] + @Type(PBA)          oid          blob        oracle
byte[] + @Type(BT)           bytea        blob        postgresql

once you use @Type, @Lob seems to not be relevant
note: oracle seems to have deprecated the "raw" type since 8i.

Büyük veritabanları arasında taşınabilir olan tek bir açıklamalı sınıfa (blob özelliği ile) sahip olmanın bir yolunu arıyorum.

• Bir bayt [] özelliğine ek açıklama eklemenin taşınabilir yolu nedir?
• Bu, hazırda bekletme modunun bazı yeni sürümlerinde düzeltildi mi?

Güncelleme: Bu blogu okuduktan sonra nihayet JIRA sorunundaki orijinal çözümün ne olduğunu anladım: Görünüşe göre @Lob'u bırakmanız ve mülke şu şekilde açıklama eklemeniz gerekiyor:

@Type(type="org.hibernate.type.PrimitiveByteArrayBlobType") 
byte[] getValueBuffer() {...

Ancak bu benim için çalışmıyor - yine de bayt yerine OID'ler alıyorum; Ancak oid istiyor gibi görünen JIRA sayısının yazarı için işe yaradı.

A. Garcia'nın cevabından sonra, postgresql üzerinde çalışan ama oracle üzerinde çalışmayan bu kombinasyonu denedim.

@Type(type="org.hibernate.type.BinaryType") 
byte[] getValueBuffer() {...

Gerçekten yapmam gereken, hangi @ org.hibernate.annotations.Type kombinasyonunu (@Lob + bayt [] eşlenir) (postgresql üzerinde) olarak kontrol etmektir.

MaterializedBlobType (sql type Blob) 'dan 3.5.5.Final'den gelen snippet. Steve'in bloguna göre postgresql, Akışları bayt için (nedenini sorma) ve oids için postgresql'in özel Blob türünü kullanmanızı istiyor. JDBC üzerinde setBytes () kullanmanın da bayt için olduğunu unutmayın (geçmiş deneyimlerden). Dolayısıyla bu, kullanım akışlarının neden her ikisinin de 'bayt' olduğunu varsaydığı bir etkisinin olmadığını açıklıyor.

public void set(PreparedStatement st, Object value, int index) {
 byte[] internalValue = toInternalFormat( value );
 if ( Environment.useStreamsForBinary() ) {
  // use streams = true
   st.setBinaryStream( index, 
    new ByteArrayInputStream( internalValue ), internalValue.length );
 }
 else {
  // use streams = false
  st.setBytes( index, internalValue );
 }
}

Bunun sonucu:

ERROR: column "signature" is of type oid but expression is of type bytea

Güncelleme Bir sonraki mantıksal soru şudur: "neden tablo tanımlarını manuel olarak bayt olarak değiştirip (@Lob + bayt []) tutmuyoruz? Bu does , işi KADAR sen [] boş byte depolamak deneyin. PostgreSQL sürücüsünün bir OID türü ifade olduğunu düşündüğü ve sütun türü bayttır - bunun nedeni, PG sürücüsünün beklediği JDBC.setBytes (null) yerine hibernate'in (haklı olarak) JDBC.setNull () işlevini çağırmasıdır.

ERROR: column "signature" is of type bytea but expression is of type oid

Hazırda bekletme modundaki tür sistemi şu anda 'devam eden bir çalışma'dır (3.5.5 kullanımdan kaldırma açıklamasına göre). Aslında 3.5.5 kodunun büyük bir kısmı kullanımdan kaldırılmıştır, PostgreSQLDialect'i alt sınıflara ayırırken neye bakılması gerektiğini bilmek zordur).

AFAKT, Types.BLOB / postgresql üzerindeki 'oid', OID tarzı JDBC erişimini kullanan bazı özel türlerle eşlenmelidir (yani PostgresqlBlobType nesnesi ve NOT MaterializedBlobType). Postgresql ile Blobları asla başarılı bir şekilde kullanmadım, ancak bayt'ın sadece beklediğim gibi çalıştığını biliyorum.

Şu anda BatchUpdateException'a bakıyorum - sürücünün gruplamayı desteklememesi olası.

2004'ten harika bir alıntı: "Saçmalıklarımı özetlemek gerekirse, Hibernate'i değiştirmeden önce JDBC sürücüsünün LOB'ları düzgün bir şekilde yapmasını beklememiz gerektiğini söyleyebilirim."

Referanslar:

• https://forum.hibernate.org/viewtopic.php?p=2393203
• https://forum.hibernate.org/viewtopic.php?p=2435174
• http://hibernate.atlassian.net/browse/HHH-4617
• http://postgresql.1045698.n5.nabble.com/Migration-to-Hibernate-3-5-final-td2175339.html
• https://jira.springframework.org/browse/SPR-2318
• https://forums.hibernate.org/viewtopic.php?p=2203382&sid=b526a17d9cf60a80f13d40cf8082aafd
• http://virgo47.wordpress.com/2008/06/13/jpa-postgresql-and-bytea-vs-oid-type/

Bir bayt [] özelliğine ek açıklama eklemenin taşınabilir yolu nedir?

Ne istediğine bağlı. JPA açıklamasız olarak kalabilir byte[]. JPA 2.0 spesifikasyonundan:

11.1.6 Temel Ek Açıklama

BasicEk açıklama, bir veritabanı sütununa eşleme en basit türüdür. BasicAçıklama aşağıdaki türlerden herhangi birinin kalıcı bir özelliği veya örneği değişken uygulanabilir: Java ilkel tipleri, temel tip sarma, java.lang.String, java.math.BigInteger, java.math.BigDecimal, java.util.Date, java.util.Calendar, java.sql.Date, java.sql.Time, java.sql.Timestamp, byte[],Byte[] , char[], Character[], enums ve diğer bir tipi, takma Serializable. Bölüm 2.8'de açıklandığı gibi Basic, bu türlerin kalıcı alanları ve özellikleri için ek açıklamanın kullanımı isteğe bağlıdır. Bu tür bir alan veya özellik için Temel ek açıklama belirtilmezse, Temel ek açıklamanın varsayılan değerleri uygulanır.

Ve hazırda bir SQL "Varsayılan olarak" bir eşler VARBINARY(veya SQL LONGVARBINARYbağlı Columnboyutta?) Bir o PostgreSQL kolları bytea.

Ancak byte[], bir Büyük Nesnede saklanmasını istiyorsanız, bir @Lob. Spesifikasyondan:

11.1.24 Lob Notu

Bir Lobkalıcı bir özellik veya alan, veri tabanı destekli büyük nesne türüne büyük bir nesne olarak kalıcı gereken açıklama belirtir. Taşınabilir uygulamalar, Lobbir veritabanı Lobtürüne eşleme yaparken ek açıklamayı kullanmalıdır . LobAçıklama Temel açıklama ile ya da birlikte kullanılabilecek ElementCollectioneleman toplama değer temel tipte olduğunda açıklama. A Lob, ikili veya karakter tipi olabilir. LobTipi dize ve karakter tipleri, Blob varsayılan dışında kalıcı alanın veya mülk türü anlaşılmaktadır ve kapanır.

Ve Hibernate, BLOBPostgreSQL'in bir oid .

Bu, hazırda bekletme modunun bazı yeni sürümlerinde düzeltildi mi?

Sorun şu ki, sorunun tam olarak ne olduğunu bilmiyorum. Ama en azından 3.5.x dalında 3.5.0-Beta-2'den (bir değişikliğin getirildiği yer) bu yana hiçbir şeyin değişmediğini söyleyebilirim.

Ancak HHH-4876 , HHH-4617 ve PostgreSQL ve BLOB'lar ( javadoc'unda bahsedilmiştir) gibi konular hakkında benim PostgreSQLDialectşu özelliği ayarlamanız gerektiğidir.

hibernate.jdbc.use_streams_for_binary=false

oidie byte[]ile kullanmak istiyorsanız @Lob(ki benim anladığım kadarıyla VARBINARYOracle ile istediğiniz şey bu değil). Bunu denedin mi

Alternatif olarak HHH-4876PrimitiveByteArrayBlobType , eski davranışı elde etmek için kullanımdan kaldırılanı kullanmayı önerir (Hazırda Bekletme 3.5 öncesi).

Referanslar

• JPA 2.0 Özellikleri
  • Kısım 2.8 "İlişkisiz Alanlar veya Özellikler için Varsayılan Eşleme"
  • Bölüm 11.1.6 "Temel Ek Açıklama"
  • Bölüm 11.1.24 "Lob Ek Açıklaması"

kaynaklar

• http://opensource.atlassian.com/projects/hibernate/browse/HHH-4876
• http://opensource.atlassian.com/projects/hibernate/browse/HHH-4617
• http://relation.to/Bloggers/PostgreSQLAndBLOBs

O'reilly Enterprise JavaBeans, 3.0'ın söylediklerine bakalım

JDBC'nin bu çok büyük nesneler için özel türleri vardır. Java.sql.Blob türü ikili verileri ve java.sql.Clob karakter verilerini temsil eder.

İşte PostgreSQLDialect kaynak kodu

public PostgreSQLDialect() {
    super();
    ...
    registerColumnType(Types.VARBINARY, "bytea");
    /**
      * Notice it maps java.sql.Types.BLOB as oid
      */
    registerColumnType(Types.BLOB, "oid");
}

Peki ne yapabilirsin

PostgreSQLDialect'i aşağıdaki gibi geçersiz kılın

public class CustomPostgreSQLDialect extends PostgreSQLDialect {

    public CustomPostgreSQLDialect() {
        super();

        registerColumnType(Types.BLOB, "bytea");
    }
}

Şimdi sadece özel lehçenizi tanımlayın

<property name="hibernate.dialect" value="br.com.ar.dialect.CustomPostgreSQLDialect"/>

Ve taşınabilir JPA @Lob ek açıklamanızı kullanın

@Lob
public byte[] getValueBuffer() {

GÜNCELLEME

İşte burada çıkarıldı

3.3.2 hazırda bekletme modunda çalışan bir uygulamam var ve uygulamalar düzgün çalışıyor , tüm blob alanları oid (java'da bayt []) kullanıyor

...

Hazırda bekletme 3.5'e geçiş tüm blob alanları artık çalışmıyor ve sunucu günlüğü şunu gösteriyor: ERROR org.hibernate.util.JDBCExceptionReporter - HATA: sütun oid türünde ancak ifade bytea türünde

burada açıklanabilir

Bu genellikle pek PG JDBC içinde hata değildir , ancak 3,5 sürümünde Hibernate'in varsayılan uygulama değişikliği . Benim durumumda bağlantıda uyumlu mülk ayarlamak yardımcı olmadı .

...

3.5 - beta 2'de gördüklerimden çok daha fazlası ve bunun düzeltilip düzeltilmediğini bilmiyorum - @ Type ek açıklaması olmadan - otomatik olarak oid türünde sütun oluşturacak, ancak bunu bayt olarak okumaya çalışacağım

İlginç olanı, Types.BOLB'yi bayt olarak eşlediğinde (Bkz. CustomPostgreSQLDialect)

JDBC toplu güncellemesi yürütülemedi

eklerken veya güncellerken

Hibernate 4.2.7.SP1'i Postgres 9.3 ile kullanıyorum ve aşağıdaki çalışmaları benim için:

@Entity
public class ConfigAttribute {
  @Lob
  public byte[] getValueBuffer() {
    return m_valueBuffer;
  }
}

Oracle'ın bununla hiçbir sorunu olmadığı için ve Postgres için özel lehçe kullanıyorum:

public class PostgreSQLDialectCustom extends PostgreSQL82Dialect {

    @Override
    public SqlTypeDescriptor remapSqlTypeDescriptor(SqlTypeDescriptor sqlTypeDescriptor) {
    if (sqlTypeDescriptor.getSqlType() == java.sql.Types.BLOB) {
      return BinaryTypeDescriptor.INSTANCE;
    }
    return super.remapSqlTypeDescriptor(sqlTypeDescriptor);
  }
}

Bu çözümün avantajı, hazırda bekletme kavanozlarını el değmeden tutabilmem.

Hibernate ile ilgili daha fazla Postgres / Oracle uyumluluk sorunu için blog gönderime bakın .

Sonunda bunu çalıştırdım. A. Garcia'nın çözümüne genişler, ancak sorun hazırda bekletme türünde olduğu için MaterializedBlob türü sadece Blob> bayt eşlemesi yeterli olmadığından, kırılmış bloke desteğiyle çalışan MaterializedBlobType yerine ihtiyacımız var. Bu uygulama yalnızca bytea ile çalışır, ancak JIRA sayısında OID'yi isteyen kişi OID uygulamasına katkıda bulunabilir.

Ne yazık ki bu türleri çalışma zamanında değiştirmek bir acıdır, çünkü Diyaloğun bir parçası olmaları gerekir. Sadece bu JIRA güçlendirmesi 3.6'ya girerse mümkün olabilir.

public class PostgresqlMateralizedBlobType extends AbstractSingleColumnStandardBasicType<byte[]> {
 public static final PostgresqlMateralizedBlobType INSTANCE = new PostgresqlMateralizedBlobType();

 public PostgresqlMateralizedBlobType() {
  super( PostgresqlBlobTypeDescriptor.INSTANCE, PrimitiveByteArrayTypeDescriptor.INSTANCE );
 }

  public String getName() {
   return "materialized_blob";
  }
}

Bunların çoğu muhtemelen statik olabilir (getBinder () gerçekten yeni bir örneğe ihtiyaç duyar mı?), Ancak dahili hazırda bekletmeyi gerçekten anlamıyorum, bu yüzden bu çoğunlukla kopyala + yapıştır + değiştir.

public class PostgresqlBlobTypeDescriptor extends BlobTypeDescriptor implements SqlTypeDescriptor {
  public static final BlobTypeDescriptor INSTANCE = new PostgresqlBlobTypeDescriptor();

  public <X> ValueBinder<X> getBinder(final JavaTypeDescriptor<X> javaTypeDescriptor) {
   return new PostgresqlBlobBinder<X>(javaTypeDescriptor, this);
  }
  public <X> ValueExtractor<X> getExtractor(final JavaTypeDescriptor<X> javaTypeDescriptor) {
   return new BasicExtractor<X>( javaTypeDescriptor, this ) {
    protected X doExtract(ResultSet rs, String name, WrapperOptions options) throws SQLException { 
      return (X)rs.getBytes(name);
    }
   };
  }
}

public class PostgresqlBlobBinder<J> implements ValueBinder<J> {
 private final JavaTypeDescriptor<J> javaDescriptor;
 private final SqlTypeDescriptor sqlDescriptor;

 public PostgresqlBlobBinder(JavaTypeDescriptor<J> javaDescriptor, SqlTypeDescriptor sqlDescriptor) { 
  this.javaDescriptor = javaDescriptor; this.sqlDescriptor = sqlDescriptor;
 }  
 ...
 public final void bind(PreparedStatement st, J value, int index, WrapperOptions options) 
 throws SQLException {
  st.setBytes(index, (byte[])value);
 }
}

oracle'a [] baytı oluşturacak @Lob ek açıklamasını blob olarak ekleyerek sorunumu düzelttim, ancak bu açıklama alanı düzgün çalışmayan oid olarak oluşturacak, bayt yapmak için [] bayt olarak oluşturulmuş aşağıdaki gibi postgres

Public class PostgreSQLDialectCustom extends PostgreSQL82Dialect {
    public PostgreSQLDialectCustom() {
        System.out.println("Init PostgreSQLDialectCustom");
        registerColumnType( Types.BLOB, "bytea" );

      }

    @Override
    public SqlTypeDescriptor remapSqlTypeDescriptor(SqlTypeDescriptor sqlTypeDescriptor) {
    if (sqlTypeDescriptor.getSqlType() == java.sql.Types.BLOB) {
      return BinaryTypeDescriptor.INSTANCE;
    }
    return super.remapSqlTypeDescriptor(sqlTypeDescriptor);
  }
 }

Ayrıca, Diyalekt için parametrenin geçersiz kılınması gerekir

spring.jpa.properties.hibernate.dialect = com.ntg.common.DBCompatibilityHelper.PostgreSQLDialectCustom

ona daha fazla ipucu bulunabilir: https://dzone.com/articles/postgres-and-oracle

Postgres için XML dosyasıyla ek açıklamayı geçersiz kılarak çalıştırdım. Oracle için açıklama tutulur. Kanımca, bu durumda, en iyisi bu sorunun eşleştirmesini, xml haritalama ile biraz zerafetle geçersiz kılmaktır. Tekli / çoklu varlıkları xml eşleme ile geçersiz kılabiliriz. Bu nedenle, esas olarak desteklenen veritabanımız için açıklama ve her bir veritabanı için bir xml dosyası kullanırdık.

Not: Tek bir sınıfı geçersiz kılmamız gerekiyor, bu yüzden önemli değil. XML ile ek açıklamayı geçersiz kılmak için Örneğimden daha fazlasını okuyun

Postgres'de @Lob byte [] 'ı oid olarak kaydetmeye çalışırken kırılıyor ve String için de aynı sorun ortaya çıkıyor. Aşağıdaki kod, oracle üzerinde iyi çalışan postgres üzerinde kırılıyor.

@Lob
private String stringField;

ve

@Lob
private byte[]   someByteStream;

Postgres üzerinde yukarıdaki düzeltmek için özel hibernate.dialect altına yazdık

public class PostgreSQLDialectCustom extends PostgreSQL82Dialect{

public PostgreSQLDialectCustom()
{
    super();
    registerColumnType(Types.BLOB, "bytea");
}

 @Override
 public SqlTypeDescriptor remapSqlTypeDescriptor(SqlTypeDescriptor sqlTypeDescriptor) {
    if (Types.CLOB == sqlTypeDescriptor.getSqlType()) {
      return LongVarcharTypeDescriptor.INSTANCE;
    }
    return super.remapSqlTypeDescriptor(sqlTypeDescriptor);
  }
}

Şimdi hazırda bekletme modunda özel lehçe yapılandırın

hibernate.dialect=X.Y.Z.PostgreSQLDialectCustom   

XYZ, paket adıdır.

Şimdi iyi çalışıyor. NOT - Hazırda Bekletme sürümüm - 5.2.8. Son Postgres sürümü - 9.6.3

Beni doğru yönde yönlendirdiği için teşekkürler Justin, Pascal. Hibernate 3.5.3 ile de aynı sorunla karşılaşıyordum. Araştırmanız ve doğru sınıflara işaretçileriniz sorunu tanımlamama ve düzeltmeme yardımcı oldu.

Hala Hibernate 3.5'e takılıp kalmış ve oid + byte [] + @LoB kombinasyonunu kullananların yararı için, sorunu çözmek için yaptıklarım aşağıdadır.

1. MaterializedBlobType'ı genişleten ve oid stili erişimiyle seti ve get yöntemlerini geçersiz kılan özel bir BlobType oluşturdum.

   public class CustomBlobType extends MaterializedBlobType {
   
   private static final String POSTGRESQL_DIALECT = PostgreSQLDialect.class.getName();
   
   /**
    * Currently set dialect.
    */
   private String dialect = hibernateConfiguration.getProperty(Environment.DIALECT);
   
   /*
    * (non-Javadoc)
    * @see org.hibernate.type.AbstractBynaryType#set(java.sql.PreparedStatement, java.lang.Object, int)
    */
   @Override
   public void set(PreparedStatement st, Object value, int index) throws HibernateException, SQLException {
       byte[] internalValue = toInternalFormat(value);
   
       if (POSTGRESQL_DIALECT.equals(dialect)) {
           try {
   
   //I had access to sessionFactory through a custom sessionFactory wrapper.
   st.setBlob(index, Hibernate.createBlob(internalValue, sessionFactory.getCurrentSession()));
               } catch (SystemException e) {
                   throw new HibernateException(e);
               }
           } else {
               st.setBytes(index, internalValue);
           }
       }
   
   /*
    * (non-Javadoc)
    * @see org.hibernate.type.AbstractBynaryType#get(java.sql.ResultSet, java.lang.String)
    */
   @Override
   public Object get(ResultSet rs, String name) throws HibernateException, SQLException {
       Blob blob = rs.getBlob(name);
       if (rs.wasNull()) {
           return null;
       }
       int length = (int) blob.length();
       return toExternalFormat(blob.getBytes(1, length));
     }
   }

   2. CustomBlobType'ı Hazırda Bekletme'ye kaydedin. Bunu başarmak için yaptığım şey şu.

      hibernateConfiguration= new AnnotationConfiguration();
      Mappings mappings = hibernateConfiguration.createMappings();
      mappings.addTypeDef("materialized_blob", "x.y.z.BlobType", null);