与同一实体的一对多
我正在从数据库模式（使用 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);
...
}
I'm doing reverse engineering from the database schema (using Hibernate) and I want to have following in the resulting entity:
public class Task implements Serializable {
...
List<Task> dependentTasks = new ArrayList<Task>(0);
...
}
If I do it as a 1:N relationship, it will generate this:
public class Task implements Serializable {
...
Task task;
List<Task> dependentTasks = new ArrayList<Task>(0);
...
}
If I do it as a M:N relationship, it will generate two same Lists:
public class Task implements Serializable {
...
List<Task> dependentTasks_1 = new ArrayList<Task>(0);
List<Task> dependentTasks_2 = new ArrayList<Task>(0);
...
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
编辑 - 您的逆向工程工具正在创建任务任务；使关系成为双向的。您可以从对象和生成的配置文件中删除该属性，但关系将是单向的——您将无法再从子项转到父项。
我敢打赌，基础表有一个任务父级的列，称为 task_id 之类的列。如果删除对父项的引用，域模型将不再使用该列。
这就是使用工具为您完成工作的危险。您应该深入研究文档并了解 hibernate 中单向和双向关系之间的区别。只是好奇，为什么您的域类必须没有“任务”属性？
编辑 - 关于更改表上的约束的评论，请小心。您拥有的遗留数据模型意味着任务应该引用其父级。因此，在改变这一点时，您正在改变遗留模型所包含的关系的语义。你可能会弄坏东西。
我认为将数据库留在原处是一个更好的做法，并使您正在构建的模型符合底层关系的语义。换句话说，说“我们不想要该任务”属性是没有意义的——您的表结构意味着您想要这个，并且它可能是出于某种原因而设计的。
EDIT -- your reverse engineering tool is creating Task task; to make the relationship bidirectional. You can remove the property from the object and the resulting configuration files, but the relationship will be unidirectional -- you will no longer be able to go from children to parents.
I bet the underlying table has a column for a task's parent called something like task_id. If you remove the reference to the parent, that column will no longer be used by your domain model.
This is the danger of using tools to do the work for you. You should dig into the documentation and understand the difference between unidirectional and bidirectional relationships in hibernate. Just curious, why does your domain class have to not have the 'task' property?
EDIT -- in reference to you comment about changing the constraint on the table, be careful. The legacy data model you have IMPLIES that tasks should have references to their parents. So in changing this, you are changing the semantics of the relationships your legacy model contains. You might break things.
I think it is a better id to leave the DB where it is, and make the model you are building conform to the semantics of the underlying relationship. In other words, to say 'we don't want the task' property doesn't make sense -- your table structure implies that you want that, and it might have been designed that way for a reason.