Вы не можете удалить Коммуну, когда она связана с одной или несколькими записями Tuteur из-за ограничений внешнего ключа. Вы должны либо использовать один из параметров каскадирования, чтобы удалить зависимые записи (хотя это необычно для отношений «многие ко многим», как в вашем случае), либо вы должны написать логику, которая нарушает отношения.
Так что я предполагаю, что в вашем случае правильным решением было бы сначала очистить связь между экземпляром Commune и всеми ссылочными экземплярами Tuteur, а затем удалить экземпляр Commune.
Вы можете сделать это программно, как показано ниже:
for (Tuteur tuteur in commune.tuteurs) {
tuteur.getCommunes().remove(commune);
entityManager.persist(tuteur);
}
commune.getTuteurs().clear();
entityManager.persist(commune);
entityManager.remove(commune);
Или с парой операторов обновления JPQL.
Редактировать: я перечитал вашу трассировку стека, которая содержит следующую основную причину:
Caused by: Exception [EclipseLink-45] (Eclipse Persistence Services - 2.0.1.v20100213-r6600): org.eclipse.persistence.exceptions.DescriptorException
Exception Description: Missing mapping for field [Commune.id].
Descriptor: RelationalDescriptor(entites.Commune --> [DatabaseTable(Commune)])
Теперь, по моему опыту, EclipseLink иногда создает ложные или сбивающие с толку исключения.
Я посмотрел ваше объявление @JoinTable
и заметил, что в вашем конкретном случае опцию referenceColumnName
можно не указывать, поскольку ваш внешний ключ - это столбец @Id
целевой таблицы в обоих направлениях. Я не думаю, что это является причиной проблемы, но вы все равно можете попробовать это.
Другой вариант - просто позволить JPA и EclipseLink определить таблицу соединений. Вы делаете это, пропуская декларацию @JoinTable
. Если у вас нет особой причины для ручного объявления таблицы соединений, то в любом случае это путь. Помните, что многие улучшения в EJB 3.0 связаны с соглашением о контроле, чтобы сократить код и требования к конфигурации котельной плиты.