Как создать Clob в JPA независимым от реализации способом

Question

Я использую Ejb3 и JPA (на данный момент на основе Hibernate и Oracle 10g)

У меня есть сущность, которая содержит сгусток

@Entity
@Table(name = "My_TAB")
public class ExampleEntity implements java.io.Serializable {

    private Clob someText;

    public void setSomeText(Clob someText) {
        this.someText= someText;
    }

    @Column(name = "COLUMN_NAME")
    public Clob getSomeText() {
        return this.someText;
    }

Тогда я хочу сохранить объект этого типа.

На данный момент я делаю следующее, что работает отлично

ExampleEntity exampleEntity = new ExampleEntity();
exampleEntity.setSomeText(Hibernate.createClob(aStringValue));
someOtherDao.save(exampleEntity);

Однако это связывает мой код с Hibernate! До сих пор я специально избегал расширений Hibernate и использовал только аннотации JPA. Код работает, потому что Hibernate действительно является моей текущей реализацией.

Существует ли какой-то JPA API, который позволяет мне создавать сабб родовым способом? Поэтому, если позже я решу перейти на Toplink / EclipseLink или что-то еще, мне не придется ничего менять?

Answer 1

Вот такой пример - спецификация JPA (§ 9.1.5)

@Column(name="DESC", 
columnDefinition="CLOB NOT NULL", 
table="EMP_DETAIL") 
@Lob 
public String getDescription() { return description; }

Я считаю, что это стандартный способ для CLOB.

Answer 2

Я не уверен, что сделаю это снова, но в прошлом, когда мне приходилось ограничивать мое приложение наиболее часто используемым подмножеством типов sql, я реализовывал двоичные объекты, используя отдельную таблицу char, и сохранял их в gzipped и база 64 закодирована. Используя сопоставление XML, это было что-то вроде:

<list name="encodedValue" lazy="true" table="TABLE" cascade="all-delete-orphan">
  <key column="TABLE_ID"/>
  <index column="SEQ"/>
  <element type="string" column="LINE" length="2000"/>
</list>

В коде метод getValue извлекает результаты getEncodedValue, объединяет их все вместе, а затем декодирует и разархивирует. В качестве оптимизации я поместил столбец простых значений в родительскую таблицу и использовал его, если он мог уместиться в 2000 символов, и переходил к дочерней таблице только при необходимости.

Метод setValue сжал и закодировал его и сохранил в простом столбце, если он подходит, в противном случае разделите его на дочерние записи. Это также приводит к ленивой загрузке, и если данные помещаются в один столбец, даже не нужно выполнять отдельный запрос.

Вероятно, излишне, если вы знаете, что ваши базы данных будут поддерживать клобы, но в нашей ситуации сработало довольно хорошо.