Foreign keys in fixtures in rails 2.0?
The ActiveRecord Fixtures creates the ID column for each row by calling Fixtures. Identify on the label you gave the row in the yaml So you should be able to do something like the following: first_message_for_quentin: title: First message body: This is your first message. Recipient_id: sender_id: Identify(:aaron) % You might want to look at some of the docs for fixture label interpolation.
The ActiveRecord Fixtures creates the ID column for each row by calling Fixtures. Identify on the label you gave the row in the yaml. So you should be able to do something like the following: first_message_for_quentin: title: First message body: This is your first message.
Recipient_id: sender_id: You might want to look at some of the docs for fixture label interpolation.
Will try this later. Thanks for the docs. – Thijs Wouters Aug 7 '09 at 8:23 This didn't work.
I dug somewhat deeper and found the real problem. – Thijs Wouters Aug 7 '09 at 15:00.
The problem was in the fixture file which was created by restful authentication. Quentin: id: 1 ... aaron: id: 2 ... I removed these ids and everything is working fine.
Ahh, that would do it. – csexton Aug 10 '09 at 20:09.
After having worked with this issue for a while, I don't think it's part of the core Rails philosophy that foreign keys should not be enforced by the database. The application level validations and checks are there to provide easy, quick, human readable (think error messages) checks that work in 99.99% of the time. If your application requires more than that, you should use database level constraints.
I think this "philosophy" evolved because of the original testing frameworks used: foreign keys just proved to be a gigantic hassle when using fixtures. It's like when a "bug" becomes a "feature" because no one fixes it. At a minimum, there is a growing movement within the Rails community to enforce integrity with the database.
Check out this blog post from last month. She even links to some plugins that help provide support for handling errors (and another blog post that links to more plugins). Do a few more Google searches; I've seen other plugins that add support to migrations to create foreign keys, too.
Now, what is part of the core Rails philosophy is: Don't worry about stuff unless you actually need to. For a lot of web applications, it's probably ok if a small (probably tiny) percentage of records contain invalid data. Pages that might be affected might only very rarely be viewed, or the error can be handled gracefully already.
I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.
Related Questions
Is it alright to create foreign keys that are not really foreign keys in a database?
Primary keys and foreign keys conflict?
Should I prefer generic names or strongly typed names for the primary keys and foreign keys in a database?
Rails fixtures or similar for creating data within an app?
Rails 3 and Rspec 2 turn off transactional fixtures for individual tests?
Rails fixtures seem to be adding extra unexpected data?