<span style="font-family: Arial, sans-serif; font-size: 12px;">annotation Hibernate appropriée pour byte[]</span>

Question

J'ai une application utilisant Hibernate 3.1 et les annotations JPA. Elle contient quelques objets avec des attributs byte[] (taille de 1k à 200k). Elle utilise l'annotation JPA @Lob, et Hibernate 3.1 peut bien lire ces données sur toutes les bases de données principales -- il semble masquer les particularités des fournisseurs JDBC Blob (comme il se doit).

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

Nous avons dû passer à la version 3.5, quand nous avons découvert que Hibernate 3.5 casse (et ne répare pas) cette combinaison d'annotations dans postgresql (sans contournement). Je n'ai pas encore trouvé de solution claire jusqu'à présent, mais j'ai remarqué que si je supprime simplement le @Lob, il utilise le type postgresql bytea (qui fonctionne, mais seulement sur postgres).

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

une fois que vous utilisez @Type, @Lob semble ne plus être pertinent
note : oracle semble avoir déprécié le type "raw" depuis 8i.

Je cherche un moyen d'avoir une seule classe annotée (avec une propriété de blob) qui soit portable sur les bases de données principales.

• Quel est le moyen portable pour annoter une propriété byte[] ?
• Cela a-t-il été corrigé dans une version récente de Hibernate ?

Mise à jour : Après avoir lu ce blog, j'ai finalement compris quel était le contournement original dans l'issue JIRA : Apparemment, vous êtes censé supprimer @Lob et annoter la propriété comme suit :

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

Cependant, cela ne fonctionne pas pour moi -- j'obtiens toujours des OID au lieu de bytea ; cependant, cela a fonctionné pour l'auteur de l'issue JIRA, qui semblait vouloir oid.

Après la réponse d'A. Garcia, j'ai donc essayé cette combinaison, qui fonctionne effectivement sur postgresql, mais pas sur oracle.

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

Ce dont j'ai vraiment besoin de faire est de contrôler quel @org.hibernate.annotations.Type la combinaison (@Lob + byte[] est mappée) vers (sur postgresql).

---

Voici l'extrait de 3.5.5.Final de MaterializedBlobType (type sql Blob). Selon le blog de Steve, postgresql veut que vous utilisiez des flux pour bytea (ne me demandez pas pourquoi) et le type Blob personnalisé de postgresql pour les oid. Notez également que l'utilisation de setBytes() sur JDBC concerne également le bytea (d'après mon expérience passée). Cela explique pourquoi use-streams n'a aucun effet car ils supposent tous les deux 'bytea'.

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 );
 }
}

Cela donne :

ERREUR : la colonne "signature" est de type oid mais l'expression est de type bytea

Mise à jour La question logique suivante est : "pourquoi ne pas simplement changer manuellement les définitions de table en bytea" et conserver le (@Lob + byte[]) ? Cela fonctionne, JUSQU'À ce que vous essayiez de stocker un byte[] nul. Que le pilote postgreSQL considère comme une expression de type OID et que le type de colonne soit bytea -- ceci est dû au fait qu'hibernate (à juste titre) appelle JDBC.setNull() au lieu de JDBC.setBytes(null) comme attendu par le pilote PG.

ERREUR : la colonne "signature" est de type bytea mais l'expression est de type oid

Le système de types dans hibernate est actuellement un 'travail en cours' (selon le commentaire de dépréciation de 3.5.5). En fait, tellement de code de la version 3.5.5 est déprécié, qu'il est difficile de savoir à quoi il faut faire attention lors de la sous-classe de PostgreSQLDialect).

AFAKT, les types Types.BLOB/'oid' sur postgresql devraient être mappés vers un type personnalisé qui utilise un accès JDBC de style OID (c'est-à-dire un objet PostgresqlBlobType et PAS MaterializedBlobType). Je n'ai jamais réellement utilisé avec succès des Blobs avec postgresql, mais je sais que bytea fonctionne simplement comme prévu.

Je regarde actuellement l'exception BatchUpdateException -- il est possible que le pilote ne prenne pas en charge le mode batch.

---

Excellente citation de 2004 : "Pour résumer mes divagations, je dirais que nous devrions attendre que le pilote JDBC gère correctement les LOBs avant de modifier Hibernate."

Références :

• 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/

Answer 1

Quelle est la manière portable d'annoter une propriété byte[] ?

Cela dépend de ce que vous voulez. JPA peut persister un byte[] non annoté. Selon la spécification JPA 2.0 :

11.1.6 Annotation de Base

L'annotation Basic est le type de mappage le plus simple vers une colonne de base de données. L'annotation Basic peut être appliquée à une propriété persistante ou à une variable d'instance de l'un des types suivants : primitifs Java, types des enrouleurs des types primitifs, 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[], des énumérations, et tout autre type qui implémente Serializable. Comme décrit dans la Section 2.8, l'utilisation de l'annotation Basic est facultative pour les champs et propriétés persistants de ces types. Si l'annotation Basic n'est pas spécifiée pour un tel champ ou propriété, les valeurs par défaut de l'annotation Basic seront appliquées.

Et Hibernate le mappera "par défaut" vers un VARBINARY SQL (ou un LONGVARBINARY SQL en fonction de la taille de Column) que PostgreSQL manipule avec un bytea.

Mais si vous souhaitez que le byte[] soit stocké dans un Objet Large, vous devriez utiliser un @Lob. Selon la spécification :

11.1.24 Annotation Lob

Une annotation Lob spécifie qu'une propriété persistante ou un champ devrait être persisté en tant qu'objet large vers un type d'objet large pris en charge par la base de données. Les applications portables devraient utiliser l'annotation Lob lors du mappage vers un type Lob de base de données. L'annotation Lob peut être utilisée conjointement avec l'annotation Basic ou avec l'annotation ElementCollection lorsque la valeur de la collection d'éléments est de type basique. Un Lob peut être de type binaire ou de type caractère. Le type Lob est déduit du type du champ ou de la propriété persistante et, sauf pour les types de chaînes et de caractères, il défaut Blob.

Et Hibernate le mappera vers un BLOB SQL que PostgreSQL manipule avec un oid.

Est-ce que c'est corrigé dans une version récente de Hibernate ?

Eh bien, le problème est que je ne sais pas exactement quel est le problème. Mais je peux au moins dire que rien n'a changé depuis 3.5.0-Beta-2 (moment où un changement a été introduit)dans la branche 3.5.x.

Mais d'après ce que je comprends des problèmes comme HHH-4876, HHH-4617 et de PostgreSQL et BLOBs (mentionné dans la javadoc du PostgreSQLDialect), vous devez définir la propriété suivante

hibernate.jdbc.use_streams_for_binary=false

si vous voulez utiliser oid c'est-à-dire byte[] avec @Lob (ce que je comprends puisque VARBINARY n'est pas ce que vous voulez avec Oracle). Avez-vous essayé ceci ?

En tant qu'alternative, HHH-4876 suggère d'utiliser le PrimitiveByteArrayBlobType obsolète pour obtenir l'ancien comportement (avant Hibernate 3.5).

Références

• Spécification JPA 2.0
  • Section 2.8 "Mapping Defaults for Non-Relationship Fields or Properties"
  • Section 11.1.6 "Basic Annotation"
  • Section 11.1.24 "Lob Annotation"

Ressources

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

Answer 2

Ici ce que déclare O'Reilly Enterprise JavaBeans, 3.0

JDBC a des types spéciaux pour ces très gros objets. Le type java.sql.Blob représente des données binaires, et java.sql.Clob représente des données de caractères.

Ici le code source de PostgreSQLDialect

public PostgreSQLDialect() {
    super();
    ...
    registerColumnType(Types.VARBINARY, "bytea");
    /**
      * Remarquez qu'il associe java.sql.Types.BLOB à oid
      */
    registerColumnType(Types.BLOB, "oid");
}

Alors voici ce que vous pouvez faire

Surchargez PostgreSQLDialect comme suit

public class CustomPostgreSQLDialect extends PostgreSQLDialect {

    public CustomPostgreSQLDialect() {
        super();

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

Maintenant définissez simplement votre dialecte personnalisé

Et utilisez votre annotation JPA portable @Lob

@Lob
public byte[] getValueBuffer() {

MISE À JOUR

Voici ce qui a été extrait ici

J'ai une application tournant sous hibernate 3.3.2 et l'application fonctionne parfaitement, avec tous les champs blob utilisant oid (byte[] en java)

...

En migratant vers hibernate 3.5, tous les champs blob ne fonctionnent plus, et le journal du serveur montre: ERREUR org.hibernate.util.JDBCExceptionReporter - ERREUR: la colonne est de type oid mais l'expression est de type bytea

ce qui peut être expliqué ici

Il ne s'agit généralement pas d'un bug dans PG JDBC, mais d'un changement d'implémentation par défaut de Hibernate dans la version 3.5. Dans ma situation, définir une propriété compatible sur la connexion n'a pas aidé.

...

Ce que j'ai vu en 3.5 - beta 2, et je ne sais pas si cela a été corrigé, c'est qu'Hibernate - sans l'annotation @Type - créera automatiquement une colonne de type oid, mais essaiera de la lire comme bytea

C'est intéressant car lorsqu'il mappe Types.BLOB en bytea (Voir CustomPostgreSQLDialect), il obtient

Impossible d'exécuter une mise à jour en lot JDBC

lors de l'insertion ou de la mise à jour

Answer 3

Je utilise le Hibernate 4.2.7.SP1 avec Postgres 9.3 et ce qui suit fonctionne pour moi :

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

comme Oracle n'a aucun problème avec cela, et pour Postgres j'utilise un dialecte personnalisé :

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);
  }
}

l'avantage de cette solution que je considère, c'est que je peux garder les jars hibernate intacts.

Pour d'autres problèmes de compatibilité Postgres/Oracle avec Hibernate, consultez mon article de blog.

Answer 4

J'ai enfin réussi à faire fonctionner cela. Cela complète la solution de A. Garcia, cependant, puisque le problème réside dans le type Hibernate MaterializedBlob, il ne suffit pas de mapper Blob > bytea, nous avons besoin d'un remplacement pour MaterializedBlobType qui fonctionne avec le support blob cassé d'Hibernate. Cette implémentation ne fonctionne qu'avec bytea, mais peut-être que le gars de l'incident JIRA qui voulait OID pourrait contribuer à une implémentation OID.

Malheureusement, remplacer ces types à l'exécution est pénible, car ils devraient faire partie du Dialecte. Si seulement cette amélioration JIRA était incluse dans la version 3.6, cela serait possible.

public class PostgresqlMateralizedBlobType extends AbstractSingleColumnStandardBasicType {
 public static final PostgresqlMateralizedBlobType INSTANCE = new PostgresqlMateralizedBlobType();

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

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

Une grande partie de cela pourrait probablement être statique (est-ce que getBinder() a vraiment besoin d'une nouvelle instance ?), mais je ne comprends pas vraiment l'implémentation interne de Hibernate, donc c'est principalement du copier-coller + modification.

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

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

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

 public PostgresqlBlobBinder(JavaTypeDescriptor 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);
 }
}

Answer 5

J'ai réussi à le faire en remplaçant l'annotation par un fichier XML pour Postgres. L'annotation est conservée pour Oracle. À mon avis, dans ce cas, il serait préférable de remplacer la cartographie de cette entité problématique par une cartographie XML. Nous pouvons remplacer une ou plusieurs entités avec une cartographie XML. Ainsi, nous utiliserions l'annotation pour notre base de données principalement supportée, et un fichier XML pour chaque autre base de données.

Remarque : nous avons juste besoin de remplacer une seule classe, donc ce n'est pas une grosse affaire. En savoir plus à partir de mon exemple Exemple de remplacement de l'annotation par XML