As people have pointed out, using DB foreign key constraints within
rails can be a nightmare when it comes to fixtures. In the past when I
have used DB constraints I have always disabled the constraints when
loading the fixtures so it wouldn't be an issue. The way I did it was
the following:
class Fixtures
alias :original_delete_existing_fixtures :delete_existing_fixtures
alias :original_insert_fixtures :insert_fixtures
def delete_existing_fixtures
@connection.update "SET FOREIGN_KEY_CHECKS = 0", 'Fixtures
deactivate foreign key checks.';
original_delete_existing_fixtures
@connection.update "SET FOREIGN_KEY_CHECKS = 1", 'Fixtures
activate foreign key checks.';
end
def insert_fixtures
@connection.update "SET FOREIGN_KEY_CHECKS = 0", 'Fixtures
deactivate foreign key checks.';
original_insert_fixtures
@connection.update "SET FOREIGN_KEY_CHECKS = 1", 'Fixtures
activate foreign key checks.';
end
end
Note, that this is MySQL specific and I would place this is my
test_helper.rb (this was pre-rSpec.) I have not used this code with
rpsec but since rspec uses rails Fixtures class (right?) you should be
able to use this as well.
-Ben
Jim Deville wrote:
> On Aug 27, 2007, at 8:08 AM, David Chelimsky wrote:
>
>
>> On 8/27/07, Jay Levitt <[EMAIL PROTECTED]> wrote:
>>
>>> Tilmann Singer wrote:
>>>
>>>> * Jay Levitt <[EMAIL PROTECTED]> [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.
>
> Jim
>
>
>>> 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
>>> [email protected]
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>>
>> _______________________________________________
>> rspec-users mailing list
>> [email protected]
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
> _______________________________________________
> rspec-users mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
