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.
Best Answer
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.