So, let me ask you the opposite. Why not supporting FKC?
Define, precisely, what you mean by support. Is it just
the ability to set a foreign key constraint in the AR
migration? Or, do you desire more pervasive support for
Fks in AR? If so then what would this support comprise?
I'll state the exact description in the end of this message.
If the prevailing RoR application type is a mostly read
only environment, with few inserts having limited cross
referencing and fewer still updates, then exactly what
benefits would integral AR foreign key support provide to
the typical RoR application user?
I've already listed the benefits in my prior mail and I won't repeat them.
In my own case, since I always use PostgreSQL and since
the Red Hill plugin to add Fk support to AR in has been
around almost from the outset, I have never had to do
without Fk support in RoR. Basically, if you know that you
need Fk support in an RoR application then you can get it.
My first message answers this:
"This is specially important for open-source projects like Redmine/Chiliproject and Gitorious where you shouldn't be assuming what database is going to be chosen in the end point"
"...foreign keys are a key concept in RDBMS"
I don't think key concepts to RDBMS (and AR ORM is supposed to be developed with RDBMS in mind) should be delegated to plugins.
And if you do not know that you need it then you will not use it anyway.
This is not true. There are lots of web frameworks out there where the relationships are defined in the models and the database is generated by the model with the FK being created out of the box in the supported databases.
While I think such approach, taken by Grails ORM for instance, is fundamentally wrong and migrations are definitely the way to go, I still believe FK should be created in some situations when possible even if the user has no idea about it.
This is specifically what I am talking about:
some migration snippet:
This should not only create the author_id numeric column, but also create the foreign key in supported databases. For unprofessional databases it should do the best it can, like creating an index if it is possible, or even a trigger for simulating the foreign key restriction if enabled by some configuration. Also if creating the foreign key won't automatically create an index to it for some databases, such statement should also take care of creating the index too.
Note, I am not arguing against including Fk support in AR.
I have long considered its absence a real defect. But I
certainly appreciate and respect the core team's p.o.v. on
the subject given the number of backend options they must
consider if they do decide to include it as a standard
feature. One has to conserve resources for work on the
essentials before the nice-to-haves are addressed.
Exactly. But the issue here is that I consider this essential while some do not.
Now, as promised, let me layout exactly what I was talking about. I'll also borrow the method names from the foreigner gem.
1- I'm proposing the change to the "reference" type in the migrations, like described above.
2- Add add_foreign_key and remove_foreign_key to the DSL syntax
3- Add some kind of foreign key representation to the schema.rb DSL
4- Detect foreign keys when possible on db:schema:dump
Of course, 4 is optional and could be done as a low-priority issue.
I hope this clarifies what I'm asking for.