Hibernate: избегайте сохранения поля во время слияния ()

У меня есть веб-приложение, в котором пользователи могут загружать файлы (через multipart/form-data), и они сохраняются вместе со своими метаданными в БД с помощью Hibernate (@Entity class Document).

В целевой таблице есть столбец BLOB content, в котором сохраняется содержимое файлов. Затем пользователям, загружающим файлы, разрешается изменять некоторые метаданные (например, исходное имя файла) в пользовательском интерфейсе на основе GWT. С этой целью я использую Dozer для преобразования экземпляра Document в экземпляр ClientDocument, который не имеет поля content и сериализуем для GWT. Как только из браузера поступает модифицированный экземпляр ClientDocument, я конвертирую его обратно в Document и выполняю следующее:

ClientDocument document = ...;
Document entity = dozerBeanMapper.map(document, Document.class);
Session session = sessionFactory.getCurrentSession();
session.merge(entity);

В этот момент столбец content entity очищается, поскольку Dozer, очевидно, не заполнил соответствующие данные BLOB.

Есть ли способ избежать обновления этого конкретного столбца BLOB content во время merge()? Я видел, что не фиксирует поле сущности гибернации в БД, но решение @Transient у меня не работает, так как мне нужно получить content BLOB для других операций в бэкенде.

Какие-либо предложения?


person Alexander Pavlov    schedule 06.12.2012    source источник


Ответы (1)


Вы можете сказать Hibernate вообще не обновлять поле

<property name="fieldName" insert="true" update="false"/>

Используя аннотации, это будет примерно так:

@Column(insertable = true, updatable = false)

Обратите внимание, что поле может быть вставлено, что означает, что оно будет вставлено, но в следующий раз, когда вы собираетесь обновить сущность, оно не будет обновлено.

person Stanislav Bashkyrtsev    schedule 06.12.2012
comment
Отлично! Именно то, что мне нужно, так как эти блобы должны быть неизменяемыми (другое содержимое документа — это другая строка в таблице). - person Alexander Pavlov; 06.12.2012