[rspec-users] Foreign key constraints, fixtures, and rake task

Jim Deville james.deville at gmail.com
Mon Aug 27 11:34:44 EDT 2007

On Aug 27, 2007, at 8:08 AM, David Chelimsky wrote:

> On 8/27/07, Jay Levitt <lists-rspec at shopwatch.org> wrote:
>> Tilmann Singer wrote:
>>> * Jay Levitt <lists-rspec at shopwatch.org> [20070827 03:51]:
>>>> What's rake doing differently?
>>> rake spec isn't doing anything fundamentally different, but the  
>>> order
>>> the specs are run is propably randomly different from when you run
>>> them with spec so they happen to pass in one case and fail in the
>>> other.
>> Nope, it's definitely not random - script/spec works every time, rake
>> fails every time.
> By default, the spec.opts file, which is loaded w/ the rake task, but
> not implicitly with the script/spec command, uses --reverse, so the
> files are run in reverse order. That would support Tilmann's theory
> combined with your observation that they consistently pass one way and
> fail the other.
> This information should shed some light on your questions below as  
> well.
> Cheers,
> David

Just wondering about your usage of constraints. We ran into this  
issue recently and came to the conclusion that unless profiling shows  
an issue, use AR to enforce referential integrity. You might be able  
to get by using :dependent => :destroy, or one of the other options.  
As for the indexing, you can set it up on your own using add_index in  
the migration. That helps save us the headaches of migrations and  
fixture issues.

Just an idea.


>> I'm not actually using :accounts at all in my specs; it's only
>> referenced in the database constraints.  (It's tested in  
>> Test::Unit at
>> the moment.)  So the order wouldn't matter.
>> I'm sure I can work around it by loading all the fixtures in some  
>> order
>> that makes the database happy; I'm more curious as to why it happens
>> with "rake spec", and not with (what seems to be) the equivalent
>> script/spec command.
>> Unfortunately, test.log doesn't show me anything that happens  
>> during the
>> failed rake run.  I'll have to see if there's a way to turn up  
>> logging
>> on MySQL itself to see what's different, or maybe switch to a TCP  
>> socket
>> and use Wireshark (nee Ethereal).
>> Jay
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list