Whoops I totally forgot about habtm table fixtures when considering that patch idea. I'm not sure there's a good way to handle them with my approach. I should be revisiting tomorrow and will chime in with any insights. No good answers so far.
Um, I guess context might help... We're writing tests for code that runs against read-only (to our app) tables -- these are the ugly-named legacy tables that I talk about in my blog. Fixtures don't play well with the concept of read-only tables. As a workaround we tried wrapping the legacy stuff in more Rails-friendly views, but that path is troublesome also and caused us problems as far as varied support of all our database engines for updateable views. Perversely, SQLite (win32) which we use for testing on our dev boxen worked fine with fixtures on views, but bombed on our FreeBSD build server. We're in the process of migrating everyone to MySQL5 but the whole experience has been a total PITA so far. Obie On 3/6/06, Rick Olson <[EMAIL PROTECTED]> wrote: > > Additionally, Obie Fernandez recently posted about a different way of > > reworking fixtures (http://jroller.com/page/obie/20060304) that we > > might want to take a look at. Obie, if you're on the list, do you > > want to chime in here? > > That's a pretty radical change to fixtures. How do you deal with > fixtures for tables with no models, like habtm join tables? > > I think I had a patch from awhile back that let you put classes in the > fixtures. Doing this sets the class name and the table name. It just > looks funky alongside the symbols: > > fixtures :people, Project, :people_projects > > > -- > Rick Olson > http://techno-weenie.net > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core > _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
