On Jul 22, 2007, at 5:34 AM, court3nay wrote: > You can hack it (and speed up fixture loading somewhat) by monkey > patching the rails code to wrap all the fixture loading in a > transaction. This will probably solve your dependency issue
That's basically what I did. > On Jul 21, 2007, at 7:27 PM, dailer <[EMAIL PROTECTED]> wrote: >> This got me looking deeper into rails and I noticed that >> db:fixtures:load calls Fixtures.create_fixtures once for each fixture >> file. In a project that had "circular" foreign key constraints (table A.b_id must refer to B.id, and B.a_id must refer back to A.id), I monkeypatched the create_fixtures to just add them to the array/hash of loaded fixtures, and load them all in in one big transaction when needed (I also used fixture-scenarios). For this postgres install, I also had to set all constraints to deferrable in the test database schema, and then do "set constraints all deferred" in the transaction that loads the fixtures to defer constraint checking until the transaction is committed. I don't think fixtures scales well enough to bigger projects, they're workable for smaller-ish (in terms of domain) projects, but I've often seem them fall down on bigger projects, esp. when there's a lot of (admittedly bad) inter-dependencies between models. Right now, the fixture-scenarios plugin is a step in the right direction, but I wouldn't mid joining in in an effort to replace the current Fixture system in rails completely, hell, I wouldn't mind it breaking backwards-incompatibility if thats what it took. JS --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
