Slaapstand> CLOB> Oracle :(

Met dank aan non sequitor voor alle hulp. Ik heb dit werkend en ik denk dat ik alle stukken hier zal plaatsen voor toekomstig gebruik. Ongeacht alle beweringen over het upgraden van de stuurprogramma's en alles zou werken, niets van dat alles werkte voor mij. Uiteindelijk moest ik een 'org.hibernate.usertype.UserType' implementeren. Ik noemde het hetzelfde als alle voorbeelden op het web StringClobType. Bewaar voor sommige importen Ik gebruikte het voorbeeld van Clobs/Blobs gebruiken met Oracle en Hibernate. Negeer wat mij betreft de "pas op" claim.

Er was één wijziging die ik moest aanbrengen om de fusies te laten werken. Sommige methoden zijn niet geïmplementeerd in het verstrekte codevoorbeeld. Eclipse heeft het voor mij opgelost door ze eruit te stoten. Cool, maar de vervangingsmethode moet daadwerkelijk worden geïmplementeerd, anders overschrijven alle samenvoegingen de gegevens met een null. Hier is mijn implementatie:

public Object replace(Object newValue, Object existingValue, Object arg2)throws HibernateException {
    return newValue;
}

Ik zal de klasse-implementatie hier niet dupliceren, ga naar de bovenstaande link om het te zien. Ik gebruikte de code in het derde grijze vak. Bovenaan de pojo-klasse waarin ik het wilde gebruiken, heb ik het volgende toegevoegd na de import

...  
import org.hibernate.annotations.Type;  
import org.hibernate.annotations.TypeDefs;  
import org.hibernate.annotations.TypeDef;  

@TypeDefs({  
    @TypeDef(  
        name="clob",  
        typeClass = foo.StringClobType.class  
    )  
})  
@Entity  
@Table(name="EA_COMMENTS")  
public class Comment extends SWDataObject implements JSONString, Serializable {  
...  
}   

Om het nieuwe UserType te gebruiken heb ik de annotatie toegevoegd aan mijn getter:

@Type(type="clob")
@Column(name="COMMENT_DOC")
public String getDocument(){
    return get("Document");
}

Ik had de @Lob-annotatie niet nodig.
In mijn persistence.xml eindigde de declaratie van de persistentie-eenheid er als volgt uit:

<persistence-unit name="###" transaction-type="RESOURCE_LOCAL">
    <provider>org.hibernate.ejb.HibernatePersistence</provider>
    <properties>
        <property name="hibernate.archive.autodetection" value="class"/> 
        <property name="hibernate.connection.password" value="###" />
        <property name="hibernate.connection.username" value="###" />
        <property name="hibernate.connection.url" value="jdbc:oracle:thin:@server.something.com:1521:###"/>
        <property name="hibernate.connection.driver_class" value="oracle.jdbc.OracleDriver"/>
        <property name="hibernate.default_schema" value="###" />
        <property name="hibernate.dialect" value="org.hibernate.dialect.Oracle9iDialect" />
        <property name="hibernate.c3p0.min_size" value="5" />
        <property name="hibernate.c3p0.max_size" value="100" />
        <property name="hibernate.c3p0.timeout" value="300" />
        <property name="hibernate.c3p0.max_statements" value="50" />
        <property name="hibernate.c3p0.idle_test period" value="3000" />
        <property name="hibernate.c3p0.idle_connection_test_period" value="300" />
        <property name="show_sql" value="false" />
        <property name="format_sql" value="false" />
        <property name="use_sql_comments" value="false" />
        <property name="hibernate.jdbc.batch_size" value="0"/>
    </properties>
</persistence-unit>

De SetBigStringTryClob heeft nooit voor mij gewerkt en was niet nodig voor deze uiteindelijke implementatie.

Mijn geleerde les is dat het uiteindelijk waarschijnlijk beter is om mee te doen dan om te vechten. Het zou me drie dagen hebben bespaard.