Just make it optional, changing the default in application.rb. I agree with no foreign keys by default, since it is what happens right now.
You can’t update rails and have all your migrations magically starting to add FKs.
Just make it optional, changing the default in application.rb. I agree with no foreign keys by default, since it is what happens right now.
You can’t update rails and have all your migrations magically starting to add FKs.
I do not think that is what the OP means. I believe that he is trying to say that implementing a non-cascading Fk at the DBMS level can be considered a 'backstop' to any application logic in (or missing from) the model. This may be considered similar to how the NOT NULL constraint at the DBMS level is presently used inside AR. It just catches logic errors before they hit the DB.
Sure James, sorry about that. I should have read it more carefully.
And I also think that we should be explicit about cascading too while declaring a "reference" type in the migrations.
Even in the database level, cascading (null or delete) should not be considered the default for foreign keys since this is very specific to the use case.
Postgres does not automatically create indexes for foreign keys, and for good reason. Consider a "categories" table with an id, name, and several other columns. It has only 5 rows. Then you have an "items" table with a million rows. It has a category_id, and you make it a foreign key. Adding an index with such a low cardinality is a Bad Idea™ because 1. it will likely never be used by the query planner 2. it will always slow down all writes to that table.
Yes, I was referring exactly to PostgreSQL. Don't you think that for most associations we would want an index?
I'm proposing creating one unless specified not to. For example:
t.references :category, create_index: false
Don't you think 'true' should be default for :create_index?
I would caution against adding such 'invisible' 'enhancements'. The more so given the wide variability of DBMS implementations. Better I think to leave everything having to do with foreign keys off by default and have the DBA specify case by case exactly which features should be turned on.
Foreign keys are one of those things that prompt religious wars and I would rather have Rails avoid adopting one side or the other as dogma.
You might be right. Anyway, I would be happy if I would have to pass "create_index: true" manually for most foreign keys too.
That would be ok to me too. I don't really mind about those details...