SubSonic 3 ActiveRecord 迁移忽略外键
使用 SubSonic 3 ActiveRecord，我从具有外键的现有数据库生成了代码。为了确保切换数据库时数据库架构始终正确，我将迁移代码放置在应用程序的开头，对生成的每个类使用 IDataProvider.MigrateToDatabase<MyClass>()由 ActiveRecord.tt 提供。事实证明，迁移代码不会重新生成外键。
我应该如何处理 FK：
- 完全忘记 FK，并在代码中处理级联删除。优点：Rails 方式的业务逻辑保留在代码中。缺点：需要处理事务，代码变得丑陋很多；如果数据库被切换/清除，数据库和ActiveRecord之间的模式往返将变得不可能（需要始终保留原始模式来重新生成/修改AR代码，否则生成的一对多属性将丢失？）；而且，我的同事可能会认为我疯了。
- 向迁移添加一个步骤以手动创建 FK。优点：模式将始终是最新的； AR 代码始终可以重新生成。缺点：数据库依赖性（小问题？）
- 以某种方式找到一种方法在代码中定义 FK 关系，以便可以正确迁移模式。
我做错了吗？我将不胜感激任何建议。
Using SubSonic 3 ActiveRecord, I generated code from an existing database that had foreign keys. To ensure database schema is always correct when switching databases, I placed migration code at the beginning of the app, using IDataProvider.MigrateToDatabase<MyClass>() for each class generated by ActiveRecord.tt. Turns out, migration code doesn't regenerate foreign keys.
How should I deal with FKs:
- Forget FKs altogether and handle cascaded deletes in the code. Pros: The Rails way, business logic is kept in the code. Cons: need to handle transactions, code becomes much uglier; schema roundtrip between database and ActiveRecord becomes impossible if database is switched/cleared (need to always keep the original schema to regenerate/modify AR code, otherwise generated one-to-many properties will be lost?); also, my colleagues may think I'm mad.
- Add a step to migrations to create FKs manually. Pros: schema will always be up to date; AR code will always be possible to regenerate. Cons: database dependency (minor issue?)
- Somehow find a way to define FK relationships in the code so that schema can be properly migrated.
Am I doing it wrong? I'd appreciate any advice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我现在正在为课程做 FK 的东西，不管你信不信——这相当困难。如果您的父类包含子类的列表 - 它是很多/很多吗？也许 - 如果你的子类包含一个引用。这是一个很弱的假设（双向不是一个好的设计）。
反正。
AR 更适合数据库优先的人 - 因此，根据您的喜好创建数据库，然后运行 AR 模板。您的 FK 将受到尊重等等。
I'm working on FK stuff right now for classes and believe it or not - it's pretty difficult. If your parent class contains a list of a child class - is it many/many? Maybe - if your child class contains a reference back. That's a weak assumption (bi-directional is not a good design).
Anyway.
AR is meant more for DB-first people - so create your DB as you like, then run AR templates. Your FKs will be honored and so forth.