Операторы обновления и удаления JPQL должны ссылаться на имя объекта, а не на имя таблицы, поэтому я думаю, вам не повезло с предложенным вами подходом.
В зависимости от в вашем провайдере JPA вы можете удалить записи из JoinTable, используя простой необработанный оператор SQL (должен быть на 100% переносимым), а затем программно взаимодействовать с API вашего провайдера кеша, чтобы удалить данные. Например, в Hibernate вы можете вызвать evict (), чтобы удалить все коллекции "Role.privs" из кеша 2-го уровня:
sessionFactory.evictCollection("Role.privs", roleId); //evict a particular collection of privs
sessionFactory.evictCollection("Role.privs"); //evict all privs collections
К сожалению, я недостаточно работаю с API-интерфейсами JPA, чтобы точно знать, что именно поддерживается.
Если вы желая использовать waitLoop в «если», вы можете изменить «выход» на «возврат», чтобы остальная часть скрипта могла справиться с ошибочной ситуацией (нет даже сообщения пользователю о том, что не удалось, до в противном случае сценарий умирает).
Другая проблема заключается в использовании "$ test" для удержания команды, что означает, что вы не получаете расширения оболочки при фактическом выполнении, а просто при оценке. Итак, если вы скажете test = "grep \" foo \ " Это удалит записи объединяемых таблиц. Объектно-ориентированный.
Я также искал подход JPQL для удаления отношения «многие ко многим» (содержащегося в таблице объединения). Очевидно, что в ORM нет концепции таблиц, поэтому мы не можем использовать операции DELETE ... Но я бы хотел, чтобы для этих случаев был специальный оператор. Что-то вроде LINK и UNLINK. Может быть, в будущем?
В любом случае, для достижения этой потребности я работал с коллекциями, реализованными в объектных компонентах, теми, которые отображают отношения «многие ко многим».
Например, , если у меня есть класс Student, который имеет отношение "многие ко многим" с курсами:
@ManyToMany
private Collection <Courses> collCourses;
Я встраиваю в объект средства получения и установки для этой коллекции. Затем, например, из EJB, я извлекаю коллекцию с помощью получателя, добавляю или удаляю желаемый курс и, наконец, использую сеттер для назначения новой коллекции. И это' сделано. Работает отлично.
Однако меня больше всего беспокоит производительность. ORM должен хранить огромный кеш всех объектов (если я не ошибаюсь), но даже используя его для более быстрой работы, мне интересно, действительно ли получение всех и каждого элемента из коллекции действительно эффективно ...
Потому что для меня это настолько же неэффективно, как извлечение реестров из таблицы и их пост-фильтрация с использованием чистой Java вместо языка запросов, который работает напрямую или косвенно с внутренним механизмом БД (SQL, JPQL ...).