So I added an int column to site_update_frequencies, bug_tool_urls, bug_columns, and a few other tables. I used fixtures to set the values of the application_id for each of these fields as incrementing, but consistent integers.
For example the row with site_update_frequency.name = Daily always has site_update_frequency.application_id = 2 no matter how many times I reset the DB. The site_update_frequency.id field changes with each import.
The idea was that I would tell project model, which has a foreign key to site_update_frequency, to look at site_update_frequency.application_id instead of site_update_frequency.id and then I'd be able to call.
In the project model a little belongs_to :site_update_frequency magic and when I call project.site_update_frequency.name in the rails code I should get the name of the site update frequency.
But I forgot that Rails was going link the objects together through the id field of site_update_frequency. So I spent an hour wondering why project.site_update_frequency == nil
Now I know it's because the project is linked to site_update_frequency through the id column which has values kn the 10k range instead of the application_id which has them in the 1-3 range. I'm using the value of the wrong Foreign Key!!!
SMACKS FOREHEAD.... Duh.
I looked around for how to tell rails to link the tables through the application_id and I have a few ideas, but after sleeping on it I started asking a different questions.
Q: Why am I trying to use configuration over convention with Rails?
A: "Ummmm I don't know."
Q: Didn't I choose Rails because of the simplicity of its convention?
A: "Sure did!"
Q: And what does the application_id give me?
A: "Not sure... The ability to behave in a sloth-like manner?"
So I've decided to get rid of the application_id columns and simply rely on the rails standard id columns.
Mostly because application_id seems to serve no purpose other than giving me a headache.
No comments:
Post a Comment