Question

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.

Was it helpful?

Solution

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top