The Rails team make so many developers happy worldwide, it's incredible. Thank you from the bottom of my heart for making my job suck less.
---
A quick questions regarding Foreign Key support, in the past I would use these concepts normally but does this mean that before Rails did not use Foreign Keys (in the strict rdbms sense)?
Does this mean that there are now easy performance gains if you're using their new -real- foreign key support?
Using `belongs_to` or `references` in a migration is simply an alias for an integer column (that conventionally holds the id of another row) without any foreign key constraints.
Foreign key constraints aren't about performance - they are about maintaining [referential integrity].
previously...
pet.id # => 4
owner.update_attribute(:pet_id, 4)
pet.destroy
owner.pet # what should this equal?
Now this will throw an error.
pet.id # => 4
owner.update_attribute(:pet_id, 4)
pet.destroy # <= raises Error:trying to destroy a record that is referenced by the owners table.
owner.update_attribute(:pet_id, nil)
pet.destroy # no problem now.
To your first question, Rails tried to enforce some constraints at the application level, but it was lacking. I worked in a large production system and for extra safeguards their were DB level foreign key constraints. They are kind of a pain to unwind and make changes, but they can save your butt if you accidentally delete something.
---
A quick questions regarding Foreign Key support, in the past I would use these concepts normally but does this mean that before Rails did not use Foreign Keys (in the strict rdbms sense)?
Does this mean that there are now easy performance gains if you're using their new -real- foreign key support?