Why would anyone use an alien gem?
This is most likely a nob question as people use this stone and many love it, but I don't understand the purpose. I am looking at the project and it has been used here many times in places like t.references :foreign_key_table_name , :foreign_key => true
, add_foreign_key :table :foreign_key_table_name, :options
and in creation t.foreign_key :foreign_key_table_name
. Hope this was not confusing as they are out of context.
But I don't understand how this differs from which rails are built in t.references :foreign_key_table_name
, or from me just adding t.integer :foreign_key_table_name_id
? does it just make it more readable by making it clear that it is a "foreign key"? I could just add a comment instead of a gem if this is the case ... The only advantage I see is that you can move parameters like :dependent
, into hyphenation instead of having it in the model, but who is it need to?
source to share
Some databases limit the legal mechanisms to support foreign key: if someone tries to keep Child
with parent_id
out of 5, but there is Parent
a id
5, while the database itself (not Rails) will reject the entry, if there is a foreign key constraint, connecting children.parent_id
and parents.id
.
The foreign key can also indicate what happens if the parent is deleted: in MySQL, for example, we can delete or collapse dependent records, like Rails does with :dependent
, or even just reject the deletion and make a mistake instead.
Since not all database modules offer this feature, Rails offers to emulate it with :dependent
, and it's nice to have it at the software level so that dependent children can fire their callbacks destroy
when the parent is deleted. Since this feature is engine agnostic and therefore very schema independent, Rails does not handle foreign key creation / deletion. Which is where it foreigner
comes in: If your engine supports foreign key constraints and you want it to be confident about data integrity, it foreigner
can help with that.
source to share
Resuming an old question here, but ...
The presence of the rails ensures that the relationships are maintained in order within the rails themselves.
However, if your project grows to have code that also accesses these tables from other languages, this will not have the benefit of enforcing rails. These foreign key constraints are baked into the SQL tables themselves, so they can secure code without rails.
It will also protect you if you need to execute data, or otherwise manipulate your data through native SQL.
source to share
Another reason is that some SQL documentation tools look at foreign keys in the DB, so it's great to have a gem that generates them. Rails 4 added the ability to define foreign keys in the same migration that creates the table with:
t.references :something, foreign_key: true
And generators will do it for you if you use a type references
. Rails adds a something_id
default index when used foreign_key
like this
source to share