Один-ко-многим с тем же лицом - PullRequest
Новая
       26

Один-ко-многим с тем же лицом

0 голосов
/ 19 декабря 2010

Я занимаюсь реверс-инжинирингом из схемы базы данных (используя Hibernate) и хочу получить следующее в результирующей сущности: 

public class Task implements Serializable {
    ...
    List<Task> dependentTasks = new ArrayList<Task>(0);
    ...
}

Если я сделаю это как отношение 1: N, оно будетсгенерируйте это: 

public class Task implements Serializable {
    ... 
    Task task; 
    List<Task> dependentTasks = new ArrayList<Task>(0);
    ...
}

Если я сделаю это как отношение M: N, он сгенерирует два одинаковых списка: 

public class Task implements Serializable {
    ...
    List<Task> dependentTasks_1 = new ArrayList<Task>(0);
    List<Task> dependentTasks_2 = new ArrayList<Task>(0);
    ...
}

1 Ответ

0 голосов
/ 19 декабря 2010

РЕДАКТИРОВАТЬ - ваш инструмент обратного инжиниринга создает задачу; сделать отношения двунаправленными. Вы можете удалить свойство из объекта и полученных файлов конфигурации, но отношения будут однонаправленными - вы больше не сможете переходить от детей к родителям.

Бьюсь об заклад, в базовой таблице есть столбец для родителя задачи, который называется что-то вроде task_id. Если вы удалите ссылку на родителя, этот столбец больше не будет использоваться моделью вашего домена.

Это опасность использования инструментов для выполнения работы за вас. Вы должны изучить документацию и понять разницу между однонаправленными и двунаправленными отношениями в спящем режиме. Просто любопытно, почему ваш класс домена не должен иметь свойство 'task'?

РЕДАКТИРОВАТЬ - в отношении вашего комментария об изменении ограничения на таблицу, будьте осторожны. Унаследованная модель данных, которую вы имеете, подразумевает, что задачи должны иметь ссылки на своих родителей. Таким образом, изменяя это, вы меняете семантику отношений, которые содержит ваша унаследованная модель. Вы можете сломать вещи.

Я думаю, что лучше оставить базу данных там, где она есть, и привести создаваемую модель в соответствие с семантикой базовых отношений. Другими словами, говорить, что свойство «мы не хотим задачи» не имеет смысла - ваша структура таблицы подразумевает, что вы этого хотите, и она могла быть спроектирована таким образом по определенной причине.

...