Какие проблемы могут возникнуть при смешивании JPA с реализациями dao-JDBC с простым JDBC?

Question

У нас есть две команды, которые хотят получить доступ к одной базе данных с использованием разных технологий. Один использует JPA (Hibernate, если быть конкретным). Другой использует простой JDBC.

Меня попросили составить список проблем, предполагающих, что каждая команда использует конфигурацию по умолчанию и/или «лучшие практики» каждой технологии.

Это новая база данных, поэтому представьте, что схема разрабатывается исключительно командой JPA или исключительно командой JDBC, а затем они оба пытаются получить к ней доступ.

Можете ли вы поделиться опытом?

ОБНОВЛЕНИЕ: Я не прошу мнения здесь. Мне все равно, является ли JPA или JDBC «лучше». Я прошу предоставить объективный список проблем совместимости при смешивании двух технологий.

---

Вот пример того, что я ищу:

Сценарий: пользователь читает строку, изменяет его в памяти, и сохраняет его обратно в базу данных.

• Если JPA использует оптимистичную блокировку, добавив столбец version к каждой таблице.
• Когда транзакция зафиксирована, JPA проверяет, изменилась ли версия между временем чтения строки и временем ее обновления. Если версия изменилась, она выдает исключение. Если нет, это позволяет продолжить фиксацию.
• Если реализация JDBC использует блокировки таблиц (пессимистическая блокировка a.k.a.), они используют SELECT ... FOR UPDATE для предотвращения параллельных обновлений.

• Представьте себе, что произойдет, если реализация JDBC не знает о конвенции JPA и не обновляет version на фиксации:

  1. JPA читает строку, используя SELECT и видит version равным 1.
  2. JDBC читает строка с использованием SELECT ... FOR UPDATE.
  3. JDBC обновляет строку (совершая транзакцию) без увеличения version.
  4. JPA пытается обновить строку. Конец проходит, потому что version по-прежнему равен 1.
  5. JPA (шаг 4) просто сплел обновление JDBC (шаг 3).

Урок: Реализация JDBC необходимо знать, чтобы обновить version колонку.

Answer 1

Создание своего собственного списка во время ожидания других людей, чтобы ответить:

1. JPA использует оптимистическое-запирание по умолчанию. Для этого требуется добавить столбец версии и увеличивать его каждый раз, когда строка обновляется. JDBC должен был бы сделать то же самое.
2. Расходящиеся слои DAO, скорее всего, будут иметь разную модель.Значение, в любое время, когда конфигурация сопоставления JPA будет изменена, соответствующий код JDBC может сломаться бесшумно.
3. Если JPA использует каскадные правила для распространения обновлений или удалений. JDBC будет делать то же самое.
4. Если используется JPA @Id @GeneratedValue(strategy=GenerationType.SEQUENCE), он создает и использует таблицу последовательностей (например, hibernate_sequence). JDBC должен был бы сделать то же самое.
5. JDBC необходимо будет поддерживать таблицы наследования классов JPA.
6. Если JPA управляет эволюцией схемы, реализация JDBC должна будет добавить поддержку ее условностей/функций. С другой стороны, если JDBC управляет эволюцией схемы, нам нужно будет отключить функции JPA, которые влияют на схему.
7. Невозможно использовать JPA кэш второго уровня, если изменения данных за пределами JPA (любезно crizzis)