JPA / Hibernate выборочный флеш - PullRequest
0 голосов
/ 22 сентября 2011

Полагаю, я начну с

Вопрос

Есть ли способ обеспечить сброс в базу данных только тех объектов, которые были явно «помечены» каким-либо образом?

Среда

Мы используем Java EE 5, Seam 2, JBoss AS 6 и Hibernate (хотя мы пытаемся сохранить прямые зависимости Hibernate минимальными).

Цель

В настоящее время у нас есть сущности, которые отображаются на временные объекты DTO, которые затем используются на бизнес-уровне и привязываются к фасетам для представления.Когда нам нужно сохранить данные, мы сопоставляем DTO с сущностями и сохраняем их.Я хотел бы заменить DTO бизнес-объектом-оболочкой, который оборачивает сущность так, чтобы:

  • Сопоставление не требуется, поскольку бизнес-объект будет вызывать методы получения и установки для обернутой сущности вместо сохранения еесобственная копия данных.
  • При создании бизнес-объекта могут быть указаны подсказки, но если что-то не получено, то оно может быть автоматически извлечено позже, как указано в JPA.Это моя любимая мозоль.Ненавижу каждый раз, когда мне это нужно, извлекать что-то лишнее.Это часто приводит к чрезмерно сложному «деловому» коду, особенно когда имеется много данных, и это слишком медленно, чтобы получить все это заранее.Когда я звоню getRelatedStuff(), он должен просто быть там .
  • Сохранение так же просто, как «маркировка» соответствующего бизнес-объекта (-ов) и вызов сброса (я думал об использовании * 1023).* Транспортировка шва в транзакциях с ручным сбросом ).

Проблема

Проблема с этим шаблоном заключается в том, что JPA хочет и хочет сбросить все в базу данных во время сброса.Я бы лучше сказал JPA, какие сущности я хочу очистить.Все, что я не указал, не должно сбрасываться.

В качестве дополнительного вопроса, является ли этот шаблон хорошей идеей?

Ответы [ 2 ]

1 голос
/ 23 сентября 2011

Конечно, вы можете.

Просто позвоните

em.clear ();

до

em.merge ();

Это приведет к отсоединению любого объекта.Затем вы просто передаете каждый объект, который хотите объединить / сохранить, как параметры вашего метода.Это приведет к сбросу в базу данных только того объекта, который вам нужен.

Будьте осторожны, чтобы после вызова em.clear () единственным постоянным объектом был тот, который был объединен / сохранен.

1 голос
/ 22 сентября 2011

Не очень хорошая идея.В ORM способ не сбрасывать изменения в базе данных - не вносить изменения в объекты.Если вам нужен такой детальный контроль над фреймворком, который вы пытаетесь получить, то вы используете его неправильно.С Hibernate ваша бизнес-логика должна быть почти не замечая, что где-то там есть база данных.Вы думаете о Hibernate как о слое над RDBMS.Вместо этого думайте об этом больше как о карте с почти неограниченной емкостью, где вы можете хранить и получать объекты по идентификатору.Как и в случае с картой, когда вы извлекаете из нее объект и вносите в него изменения, эти изменения также отражаются на карте, а другие объекты на карте будут видеть обновленное состояние объекта.Конечно, в Hibernate изменения должны происходить в транзакции, но следует учитывать, что это транзакция памяти, необходимая, так как к карте одновременно обращаются несколько потоков.

...