Hey all, I am having a little trouble getting some referential integrity tests to work well. Right now, I am using Postgres as my database. I have generated migrations for my tables and ensured referential integrity by using execute commands. All is working well at the level of the database and application. I can get all the checks to work flawlessly if I set up my test database by issuing "rake db:migrate RAILS_ENV=test". However, if I do the more traditional approach by issuing "rake db:test:prepare and rake db:test:load," this seems to load the information from the schema.rb file. This file does not seem to contain the foreign key constraints (or other db constraints, for that matter). Any thoughts on getting this to work properly and getting the schema.rb file to recognize all the db checks? I can imagine that this will be an issue at the time of production, because the schema.rb file will not be usable for setting up the production database. It seems to me, I would have to run the migrations... Thanks, Andrew
On Sep 28, 4:44 am, Andrew Pace <andrewpp...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hey all, > > I am having a little trouble getting some referential integrity tests > to work well. > > Right now, I am using Postgres as my database. I have generated > migrations for my tables and ensured referential integrity by using > execute commands. All is working well at the level of the database > and application. I can get all the checks to work flawlessly if I set > up my test database by issuing "rake db:migrate RAILS_ENV=test". > > However, if I do the more traditional approach by issuing "rake > db:test:prepare and rake db:test:load," this seems to load the > information from the schema.rb file. This file does not seem to > contain the foreign key constraints (or other db constraints, for that > matter). >The ruby schema dumper doesn''t understand things that activerecord doesn''t, which includes foreign key constraints (There''s a plugin somewhere that adds foreign key support to active record). One way around this is to set the schema dumper format (in environment.rb) to :sql rather than ruby. Instead of generating schema.rb, RAILS_ENV.sql will be generated, using your database''s tools. Fred> Any thoughts on getting this to work properly and getting the > schema.rb file to recognize all the db checks? > > I can imagine that this will be an issue at the time of production, > because the schema.rb file will not be usable for setting up the > production database. It seems to me, I would have to run the > migrations... > > Thanks, > > Andrew
Frederick Cheung wrote:> On Sep 28, 4:44�am, Andrew Pace <andrewpp...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >> However, if I do the more traditional approach by issuing "rake >> db:test:prepare and rake db:test:load," this seems to load the >> information from the schema.rb file. �This file does not seem to >> contain the foreign key constraints (or other db constraints, for that >> matter). >> > > The ruby schema dumper doesn''t understand things that activerecord > doesn''t, which includes foreign key constraints (There''s a plugin > somewhere that adds foreign key support to active record).That would be foreign_key_migrations. You should *definitely* be using this rather than writing your foreign key constraints in execute statements. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
Andrew Pace wrote: [...]> I can imagine that this will be an issue at the time of production, > because the schema.rb file will not be usable for setting up the > production database.What do you mean, "at time of production"? Are you *really* planning to deploy to production only after everything is done? If so, you''re setting yourself up for integration hell. You should be deploying to a production server (or at least a staging server) quite frequently. Don''t wait.> It seems to me, I would have to run the > migrations...You *should* be running the migrations as you deploy each new version. (But you''re right, that''s not how you should set up the DB from scratch.)> > Thanks, > > AndrewBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.