0

This one's really an off shoot of another question I asked, earlier today.

Basically, it seems like it's not the rails way to have database level constraints (foreign keys) in RoR. At least, they're not natively supported. There's this Foreigner Gem or I could go primitive and use raw SQL through execute in rails migrations.

My question is, are there any pitfalls I need to be aware of when using the execute route. Here are a few that I that I'm aware of:

  1. Writing db seeds/fixtures can get tricky, perhaps impossible for some cases
  2. Managing db migrations becomes difficult, as the foreign keys would never be dumped in db/schema.rb
  3. Polymorphic foreign keys would not be possible (I don't even know what they are, so, I shouldn't miss those)

Are there any other pitfalls that I should be aware of?

Community
  • 1
  • 1
Code Poet
  • 11,227
  • 19
  • 64
  • 97
  • The pitfalls are that foreign keys are *annoying*, so you probably want to consider your options before applying them aggressively. – tadman Jul 04 '14 at 17:32
  • 1
    4. If you change along the way the name of your tables/models, you'll have to *manually scan* all the SQL native code to propagate those changes. – Fer García Jul 04 '14 at 18:26

0 Answers0