Я использую Ejb3, и JPA (на основе В спящем режиме и Oracle 10 г в данный момент),
У меня есть объект, который содержит clob
@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);
Однако это связывает мой код для Спящего режима! Я конкретно избежал, до сих пор В спящем режиме расширения и используемый только аннотации JPA. Работы кода, потому что действительно В спящем режиме, являются моей текущей реализацией.
Есть ли своего рода API JPA, который позволяет мне создавать clob универсальным способом? Таким образом, если позже я решаю переключиться на Toplink/EclipseLink или что-то еще, что я не должен буду изменять вещь?
Вот такой пример - спецификация JPA (§ 9.1.5)
@Column(name="DESC",
columnDefinition="CLOB NOT NULL",
table="EMP_DETAIL")
@Lob
public String getDescription() { return description; }
Я считаю, что это стандартный способ для CLOB.
Я не уверен, что сделаю это снова, но в прошлом, когда мне приходилось ограничивать свое приложение наиболее широко используемым подмножеством типов sql, Я реализовал бинарные объекты, используя отдельную таблицу символов, и сохранил их в сжатом виде и в кодировке base 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 сжал и закодировал его и сохранил в простом столбце, если он подходит, в противном случае разделил его на дочерние записи. Это также приводит к ленивой загрузке, и если данные помещаются в один столбец, даже не нужно выполнять отдельный запрос.
Наверное, излишне, если вы знаете, что ваши базы данных будут поддерживать clobs, но в нашей ситуации сработали довольно хорошо.