I'm maintaining mine -
http://github.com/willbryant/foreign_key_saver/tree/master - but it
tends to not need any changes so it's been a long time since there's
been commits. It supports all the update/delete actions, and knows
how to dump out FKs in schemas so they get restored in your test db
(etc.). I don't hook the newer association-like table DML methods as
you've suggested, but yeah I can certainly see how that would be a
useful feature for some people.
I only support mysql and postgresql in it, so will comment on how well
FKs work in them specifically, which perhaps might influence how
suitable FK support would be to have in core.
Postgresql generally I'm pretty happy with, extracting out the FKs is
a little obtuse but really nothing to complain about.
Mysql works acceptably, but there is an annoying performance caveat,
which is that Mysql does not cache the data dictionary stuff properly,
and to get the info they need to scan through all the database table
file directories on disk and open up each table definition, which is
very slow (well, relatively speaking).
As a result if you have a database with a reasonable number of tables,
you will find that, for example, dropping tables is now somewhat bit
slower (1-5s, for the one customer project I'm working on at the
moment which has ~200 tables) as this requires checking for FKs that
need to be dropped first, which hits the data dictionary.
(They have improved the speed of these operations in later versions of
Mysql, but not solved the problem - and given that the bug has been
open for several years now, it seems they are reluctant to, apparently
on the basis that they don't want to lose the support for the few odd
users who want to be able to drop new database tables into the mysql
data directories and have them immediately available without telling
the server. Not my idea of a good engineering tradeoff, but there you
I wouldn't personally think this blocks adding support to core, but
it's something to bear in mind. You should also note that mysql does
not support "delayed constraints" that are checked at transaction
commit, which makes it impossible or difficult to make certain key
changes, but since with AR basic key best practices such as not
changing PKs are very strongly encouraged, I can't see anyone caring
about that (and they could always just disable FKs or turn off
whatever option gets added, for those weird tables, anyway).
Finally, as in my readme, mysql does not support "set default" or
"restrict" on update/delete actions, so we would need to either go for
the lowest common denominator and not offer those as options, or live
with mysql not implementing all the options.
Anyway, re integration to core, I think that if we were going to add
FK support, we would need to somehow support sqlite (Firebird and
Oracle can be added fairly easily - I know of at least one other
plugin that supports them without any drama, though I would definitely
not recommend that plugin as at least of when I last looked at it as
the authors had failed to mention that they have an unrelated
monkeypatch in their plugin that changes how NULLs behave! naughty.)
I haven't attempted that (sqlite support), but their wiki explains
that they support the syntax of FK declarations but that they have no
effect; they suggest using a trigger to do this. If we could write a
standard routine to deal with these, then I suppose that Rails could
automatically create this/these routine(s) in the database when
creating an FK, but I haven't tried it (would love to hear if you do).