RE: Re: challenge has info on a similar problem. It
looks like the best way is to simply disable foreign key checks when
doing the deletion (or you may be able to use the tip I gave you, and do
a .reverse on the result before deleting the fixtures). It seems MySQL
may not have a simple way of deleting the contents of a table with
self-referencing foreign key constraints (DELETE FROM table and TRUNCATE
table don’t seem to work).


From: [email protected]
[mailto:[email protected]] On Behalf Of M Daggett
Sent: Tuesday, 22 November 2005 4:26 p.m.
To: [email protected]
Subject: Re: [Rails] Re: challenge

Hey Jonathan,
You are exactly right. It seems the real trick is not to just use a
structured YAML file but to also inform the test how to load and remove
records for use in the fixture. Right now my tests are all breaking
because I have one table of images that contains a foreign key to its
respective category. The category in turn has a key to its parent. When
the fixtures run for the first test it creates the images but when it
comes time to delete the categories and create them again for the next
test it bombs because of the image’s dependencies implicit in the
foreign key relationship.

Seems pretty tricky but at the same time foreign keys seems so obvious
and necessary that the fact that I am struggling at it makes me feel I
am using rails wrong (especially since it is so database centric). I am
using MYSQL and I am wondering if I might have less problems using
POSTGRES or something. Thanks for your tip, I’ll try it out and report


On 11/21/05, Jonathan V. [email protected] wrote:
I have run in to the same problem. It happens because the individual
fixtures aren’t loaded in the order they are declared in the YAML file.
I tracked this down to the fact that YAML::load simply returns a hash of
all fixtures in the file. A very simple way to fix this (if your
fixtures are declared in order of id) is to sort this hash before AR
tries to load it, therefore making sure the fixtures are loaded in the
correct order.

Change line 283 in lib/active_record/fixtures.rb to sort the fixtures
before inserting them:

values.sort { |a, b| a[“id”].<=>(b[“id”]) }.each do |fixture|

So they will inserted in order of id.

That partially fixes the problem, although there are still issues
surrounding foreign keys/testing/fixtures.

Cheers, -Jonny.

From: [email protected]
[mailto:[email protected]] On Behalf Of M Daggett
Sent: Tuesday, 22 November 2005 12:04 p.m.
To: [email protected]
Subject: Re: [Rails] Re: challenge

I am having a similar problem, I have a category model which is defined
to “acts_as_tree”. The table structure looks like this:

create table categories (
id INT not null auto_increment,
name VARCHAR(200) not null,
parent_id int,
description TEXT ,
created_on DATETIME null,
updated_on DATETIME null,
constraint fk_categories_to_categories foreign key (parent_id)
references categories(id),
primary key (id)

as you can see the foreign key is a reference to another row in the
table. For the root category I just have (NULL) specified for the
parent_id. However all of my unit tests are blowing up because it cannot
find the parent category for the root category (because it does not


  1. Error:
    ActiveRecord::StatementInvalid: #23000Cannot delete or update a parent
    row: a foreign key constraint fails (itsthes_test/categories,
    CONSTRAINT fk_ categories_to_categories FOREIGN KEY (parent_id) REFERENCES
    categories (id)): DELETE FROM categories

Does anyone have an idea how to solve this problem?


On 11/14/05, Joe B. [email protected] wrote:
thanks all the guys reply my “challenge”.
and “liquid” give us a good link
it’s solve this kind of problem.


Posted via

Rails mailing list
[email protected]

I am Mark Daggett and I approve this message.

Rails mailing list
[email protected]

I am Mark Daggett and I approve this message.

Hey Jonny,
Thanks for the tip, this is very useful, I may not be reading this
but is the poster saying this is a MYSQL specific problem. If I were to
migrate to Postgres would my tests pass successfully (well at least this
part)? Glad to see it is not a newbie-ish misunderstanding of how things
supposed to work. I read some information on using RAKE to generate data
the database before you run your unit tests. In this case unless I
misunderstand it you would not need to include the fixtures into the

I have bookmarked the ticket and I’ll check back on it as well as trying
fix that is posted on the ticket.