Apparently I have missed something somewhere along the line, and have made a real mess of things here.
The question/problem I'm trying to work through is, in Rails, how do you deal with a mixture of "code tables" and test fixtures. I'm not sure what "code tables" are really called, but I'm referring to tables containing data that's more like configuration. For example I've got three tables named 'authorities', 'roles' and 'authorities_roles' representing a many-to-many (habtm) relationship between authorities and roles. The authorities table is essentially static, the records will change very rarely (only when there's an update to the system). The roles table has a set of default roles, and allows users to create their own roles. Make sense?
Somewhere I thought I read that my "code table" data should be moved out of the fixtures and into a migration. Easy enough. But now my tests fail miserably. For one going from unit to functional tests, all the records are deleted.
So how do you get the migrations and fixtures to play well together?
> Apparently I have missed something somewhere along the line, and have > made a real mess of things here.
> The question/problem I'm trying to work through is, in Rails, how do > you deal with a mixture of "code tables" and test fixtures. I'm not > sure what "code tables" are really called, but I'm referring to tables > containing data that's more like configuration. For example I've got > three tables named 'authorities', 'roles' and 'authorities_roles' > representing a many-to-many (habtm) relationship between authorities > and roles. The authorities table is essentially static, the records > will change very rarely (only when there's an update to the system). > The roles table has a set of default roles, and allows users to create > their own roles. Make sense?
> Somewhere I thought I read that my "code table" data should be moved > out of the fixtures and into a migration. Easy enough. But now my > tests fail miserably. For one going from unit to functional tests, > all the records are deleted.
> So how do you get the migrations and fixtures to play well together?
> You need the data in both places. In the fixtures and in the migration > script.
> Ceaser
> On Aug 14, 2007, at 4:32 PM, "Jason Edwards" <jtan...@gmail.com> wrote:
> > Apparently I have missed something somewhere along the line, and have > > made a real mess of things here.
> > The question/problem I'm trying to work through is, in Rails, how do > > you deal with a mixture of "code tables" and test fixtures. I'm not > > sure what "code tables" are really called, but I'm referring to tables > > containing data that's more like configuration. For example I've got > > three tables named 'authorities', 'roles' and 'authorities_roles' > > representing a many-to-many (habtm) relationship between authorities > > and roles. The authorities table is essentially static, the records > > will change very rarely (only when there's an update to the system). > > The roles table has a set of default roles, and allows users to create > > their own roles. Make sense?
> > Somewhere I thought I read that my "code table" data should be moved > > out of the fixtures and into a migration. Easy enough. But now my > > tests fail miserably. For one going from unit to functional tests, > > all the records are deleted.
> > So how do you get the migrations and fixtures to play well together?
Not sure what you mean by that, Jason. The migration puts the data into your "live" database (production, or development). The fixtures put the data into your test database. If the data will always be the same in both places, have your migration read the fixtures.
- Jamis
On 8/15/07, Jason Edwards <jtan...@gmail.com> wrote:
> Well that won't work. You can't follow the DRY principle if you do that...
> Jason
> On 8/14/07, Ceaser Larry <ceaser.la...@gmail.com> wrote:
> > You need the data in both places. In the fixtures and in the migration > > script.
> > Ceaser
> > On Aug 14, 2007, at 4:32 PM, "Jason Edwards" <jtan...@gmail.com> wrote:
> > > Apparently I have missed something somewhere along the line, and have > > > made a real mess of things here.
> > > The question/problem I'm trying to work through is, in Rails, how do > > > you deal with a mixture of "code tables" and test fixtures. I'm not > > > sure what "code tables" are really called, but I'm referring to tables > > > containing data that's more like configuration. For example I've got > > > three tables named 'authorities', 'roles' and 'authorities_roles' > > > representing a many-to-many (habtm) relationship between authorities > > > and roles. The authorities table is essentially static, the records > > > will change very rarely (only when there's an update to the system). > > > The roles table has a set of default roles, and allows users to create > > > their own roles. Make sense?
> > > Somewhere I thought I read that my "code table" data should be moved > > > out of the fixtures and into a migration. Easy enough. But now my > > > tests fail miserably. For one going from unit to functional tests, > > > all the records are deleted.
> > > So how do you get the migrations and fixtures to play well together?
> Not sure what you mean by that, Jason. The migration puts the data > into your "live" database (production, or development). The fixtures > put the data into your test database. If the data will always be the > same in both places, have your migration read the fixtures.
> - Jamis
> On 8/15/07, Jason Edwards <jtan...@gmail.com> wrote:
> > Well that won't work. You can't follow the DRY principle if you do that...
> > Jason
> > On 8/14/07, Ceaser Larry <ceaser.la...@gmail.com> wrote:
> > > You need the data in both places. In the fixtures and in the migration > > > script.
> > > Ceaser
> > > On Aug 14, 2007, at 4:32 PM, "Jason Edwards" <jtan...@gmail.com> wrote:
> > > > Apparently I have missed something somewhere along the line, and have > > > > made a real mess of things here.
> > > > The question/problem I'm trying to work through is, in Rails, how do > > > > you deal with a mixture of "code tables" and test fixtures. I'm not > > > > sure what "code tables" are really called, but I'm referring to tables > > > > containing data that's more like configuration. For example I've got > > > > three tables named 'authorities', 'roles' and 'authorities_roles' > > > > representing a many-to-many (habtm) relationship between authorities > > > > and roles. The authorities table is essentially static, the records > > > > will change very rarely (only when there's an update to the system). > > > > The roles table has a set of default roles, and allows users to create > > > > their own roles. Make sense?
> > > > Somewhere I thought I read that my "code table" data should be moved > > > > out of the fixtures and into a migration. Easy enough. But now my > > > > tests fail miserably. For one going from unit to functional tests, > > > > all the records are deleted.
> > > > So how do you get the migrations and fixtures to play well together?
rake db:fixtures:load # Load fixtures into the current environment's database. Load specific fixtures using FIXTURES=x,y
For a complete listing of rake tasks that ships with rails do "rake -T". So if you want to load the fixtures into dev you would do: RAILS_ENV=development rake db:fixtures:load
Brett Rasmussen wrote: > Out of curiosity, what would I do if I wanted to load the fixtures > into the development database but don't want it part of a migration?
So I finally got it all working, just the way I wanted, but I didn't follow the advice I got. Please feel free to tell me how lame this is.
* I'm still loading my base data sets as inserts in my migrations. * My fixture files now contain *only* test fixtures, none of the base data. * I set the 'self.pre_loaded_fixtures = true' and 'self.use_transactional_fixtures = true' in my test_helper.rb * I took out all the fixture declarations in my test, and now have them load fixtures from the database. * I wrote a rake task which loads the fixtures, but doesn't delete the existing data. So I can insert data into a table in my migration, and then insert additional rows in table using the fixtures.
Now the only problem I'm having is when I run the tests with Rake, it calls 'db:test:prepare' which recreates the structure, but leaves the tables empty.
Anyone know how to change that? I was just going to write another Rake task...
> Derr, have the migrations read the fixtures, now I'm pickin' up what > you're layin' down... I'll give that a whirl.
> Thanks,
> Jason
> On 8/15/07, Jamis Buck <ja...@37signals.com> wrote:
> > Not sure what you mean by that, Jason. The migration puts the data > > into your "live" database (production, or development). The fixtures > > put the data into your test database. If the data will always be the > > same in both places, have your migration read the fixtures.
> > - Jamis
> > On 8/15/07, Jason Edwards <jtan...@gmail.com> wrote:
> > > Well that won't work. You can't follow the DRY principle if you do that...
> > > Jason
> > > On 8/14/07, Ceaser Larry <ceaser.la...@gmail.com> wrote:
> > > > You need the data in both places. In the fixtures and in the migration > > > > script.
> > > > Ceaser
> > > > On Aug 14, 2007, at 4:32 PM, "Jason Edwards" <jtan...@gmail.com> wrote:
> > > > > Apparently I have missed something somewhere along the line, and have > > > > > made a real mess of things here.
> > > > > The question/problem I'm trying to work through is, in Rails, how do > > > > > you deal with a mixture of "code tables" and test fixtures. I'm not > > > > > sure what "code tables" are really called, but I'm referring to tables > > > > > containing data that's more like configuration. For example I've got > > > > > three tables named 'authorities', 'roles' and 'authorities_roles' > > > > > representing a many-to-many (habtm) relationship between authorities > > > > > and roles. The authorities table is essentially static, the records > > > > > will change very rarely (only when there's an update to the system). > > > > > The roles table has a set of default roles, and allows users to create > > > > > their own roles. Make sense?
> > > > > Somewhere I thought I read that my "code table" data should be moved > > > > > out of the fixtures and into a migration. Easy enough. But now my > > > > > tests fail miserably. For one going from unit to functional tests, > > > > > all the records are deleted.
> > > > > So how do you get the migrations and fixtures to play well together?
Can't say I can tell you how to change that, but I would advise against having a test database that can't be torn down and rebuilt at a whim from your fixtures without breaking any tests. It'll make your life easier in the long run. Not tearing down your test database each time can leave you with extremely difficult to track down errors, false negatives and false positives and generally make your tests harder to use and less reliable.
Lee
On 8/16/07, Jason Edwards <jtan...@gmail.com> wrote:
> So I finally got it all working, just the way I wanted, but I didn't > follow the advice I got. Please feel free to tell me how lame this > is.
> * I'm still loading my base data sets as inserts in my migrations. > * My fixture files now contain *only* test fixtures, none of the base data. > * I set the 'self.pre_loaded_fixtures = true' and > 'self.use_transactional_fixtures = true' in my test_helper.rb > * I took out all the fixture declarations in my test, and now have > them load fixtures from the database. > * I wrote a rake task which loads the fixtures, but doesn't delete the > existing data. So I can insert data into a table in my migration, and > then insert additional rows in table using the fixtures.
> Now the only problem I'm having is when I run the tests with Rake, it > calls 'db:test:prepare' which recreates the structure, but leaves the > tables empty.
> Anyone know how to change that? I was just going to write another Rake task...
> On 8/15/07, Jason Edwards <jtan...@gmail.com> wrote: > > Derr, have the migrations read the fixtures, now I'm pickin' up what > > you're layin' down... I'll give that a whirl.
> > Thanks,
> > Jason
> > On 8/15/07, Jamis Buck <ja...@37signals.com> wrote:
> > > Not sure what you mean by that, Jason. The migration puts the data > > > into your "live" database (production, or development). The fixtures > > > put the data into your test database. If the data will always be the > > > same in both places, have your migration read the fixtures.
> > > - Jamis
> > > On 8/15/07, Jason Edwards <jtan...@gmail.com> wrote:
> > > > Well that won't work. You can't follow the DRY principle if you do that...
> > > > Jason
> > > > On 8/14/07, Ceaser Larry <ceaser.la...@gmail.com> wrote:
> > > > > You need the data in both places. In the fixtures and in the migration > > > > > script.
> > > > > Ceaser
> > > > > On Aug 14, 2007, at 4:32 PM, "Jason Edwards" <jtan...@gmail.com> wrote:
> > > > > > Apparently I have missed something somewhere along the line, and have > > > > > > made a real mess of things here.
> > > > > > The question/problem I'm trying to work through is, in Rails, how do > > > > > > you deal with a mixture of "code tables" and test fixtures. I'm not > > > > > > sure what "code tables" are really called, but I'm referring to tables > > > > > > containing data that's more like configuration. For example I've got > > > > > > three tables named 'authorities', 'roles' and 'authorities_roles' > > > > > > representing a many-to-many (habtm) relationship between authorities > > > > > > and roles. The authorities table is essentially static, the records > > > > > > will change very rarely (only when there's an update to the system). > > > > > > The roles table has a set of default roles, and allows users to create > > > > > > their own roles. Make sense?
> > > > > > Somewhere I thought I read that my "code table" data should be moved > > > > > > out of the fixtures and into a migration. Easy enough. But now my > > > > > > tests fail miserably. For one going from unit to functional tests, > > > > > > all the records are deleted.
> > > > > > So how do you get the migrations and fixtures to play well together?
It's not that it can't be torn down, I can tear it down, and rebuild it easily, I do it dozens of times a day. The problem is the default Rake task ('test') doesn't use my migrations, and my load_additional_fixtures task, to rebuild the test database.
In the short term I wrote a simple one-liner shell script to do exactly what I'm talking about, but now I realize that a new Rake task is definitely the way to go.
Thanks,
Jason
P.S. - In case you didn't get the memo: Ruby (metaclasses in this case) rules! Long live Ruby!
> Can't say I can tell you how to change that, but I would advise > against having a test database that can't be torn down and rebuilt at > a whim from your fixtures without breaking any tests. It'll make your > life easier in the long run. Not tearing down your test database each > time can leave you with extremely difficult to track down errors, > false negatives and false positives and generally make your tests > harder to use and less reliable.
> Lee
> On 8/16/07, Jason Edwards <jtan...@gmail.com> wrote:
> > So I finally got it all working, just the way I wanted, but I didn't > > follow the advice I got. Please feel free to tell me how lame this > > is.
> > * I'm still loading my base data sets as inserts in my migrations. > > * My fixture files now contain *only* test fixtures, none of the base data. > > * I set the 'self.pre_loaded_fixtures = true' and > > 'self.use_transactional_fixtures = true' in my test_helper.rb > > * I took out all the fixture declarations in my test, and now have > > them load fixtures from the database. > > * I wrote a rake task which loads the fixtures, but doesn't delete the > > existing data. So I can insert data into a table in my migration, and > > then insert additional rows in table using the fixtures.
> > Now the only problem I'm having is when I run the tests with Rake, it > > calls 'db:test:prepare' which recreates the structure, but leaves the > > tables empty.
> > Anyone know how to change that? I was just going to write another Rake task...
> > On 8/15/07, Jason Edwards <jtan...@gmail.com> wrote: > > > Derr, have the migrations read the fixtures, now I'm pickin' up what > > > you're layin' down... I'll give that a whirl.
> > > Thanks,
> > > Jason
> > > On 8/15/07, Jamis Buck <ja...@37signals.com> wrote:
> > > > Not sure what you mean by that, Jason. The migration puts the data > > > > into your "live" database (production, or development). The fixtures > > > > put the data into your test database. If the data will always be the > > > > same in both places, have your migration read the fixtures.
> > > > - Jamis
> > > > On 8/15/07, Jason Edwards <jtan...@gmail.com> wrote:
> > > > > Well that won't work. You can't follow the DRY principle if you do that...
> > > > > Jason
> > > > > On 8/14/07, Ceaser Larry <ceaser.la...@gmail.com> wrote:
> > > > > > You need the data in both places. In the fixtures and in the migration > > > > > > script.
> > > > > > Ceaser
> > > > > > On Aug 14, 2007, at 4:32 PM, "Jason Edwards" <jtan...@gmail.com> wrote:
> > > > > > > Apparently I have missed something somewhere along the line, and have > > > > > > > made a real mess of things here.
> > > > > > > The question/problem I'm trying to work through is, in Rails, how do > > > > > > > you deal with a mixture of "code tables" and test fixtures. I'm not > > > > > > > sure what "code tables" are really called, but I'm referring to tables > > > > > > > containing data that's more like configuration. For example I've got > > > > > > > three tables named 'authorities', 'roles' and 'authorities_roles' > > > > > > > representing a many-to-many (habtm) relationship between authorities > > > > > > > and roles. The authorities table is essentially static, the records > > > > > > > will change very rarely (only when there's an update to the system). > > > > > > > The roles table has a set of default roles, and allows users to create > > > > > > > their own roles. Make sense?
> > > > > > > Somewhere I thought I read that my "code table" data should be moved > > > > > > > out of the fixtures and into a migration. Easy enough. But now my > > > > > > > tests fail miserably. For one going from unit to functional tests, > > > > > > > all the records are deleted.
> > > > > > > So how do you get the migrations and fixtures to play well together?
