I seem to be having a problem with one of my fixtures and the foreign keys with-in. I have a basic setup where the table holds both child and parent values, (id, and parent_id). I''m using postgres so I set the parent_id to be a foreign key that references id. If i go through the console, or just using straight SQL I can create parents and childs (parents having a parent_id of nil). Whenever I go to run the test, however, it always complains that the parent_id of 1 does not exist. Heres the problem fixture: products_category: id: 1 name: Products description: Products Category software_category: id: 2 parent_id: 1 name: Software description: Software Category If I comment out all the child categories then the tests that dont look at them pass, but of course the other ones that do fail. The only thing I can think of is that its doing inserts in a transaction, and thats whats screwing things up. Any other ideas? If I could I would split the fixture up for parent/child but it doesnt like that to much either as they use the same model and can only have one fixture with the right name. Thanks for the help!! -Nick
The fixtures are loaded in sort-by-name order. I ran into this last week. There''s already a ticket to address this issue in the future. -- -- Tom Mornini On Oct 16, 2005, at 2:02 PM, Nick Stuart wrote:> I seem to be having a problem with one of my fixtures and the foreign > keys with-in. I have a basic setup where the table holds both child > and parent values, (id, and parent_id). I''m using postgres so I set > the parent_id to be a foreign key that references id. > > If i go through the console, or just using straight SQL I can create > parents and childs (parents having a parent_id of nil). Whenever I go > to run the test, however, it always complains that the parent_id of 1 > does not exist. Heres the problem fixture: > products_category: > id: 1 > name: Products > description: Products Category > software_category: > id: 2 > parent_id: 1 > name: Software > description: Software Category > > If I comment out all the child categories then the tests that dont > look at them pass, but of course the other ones that do fail. The only > thing I can think of is that its doing inserts in a transaction, and > thats whats screwing things up. Any other ideas? > > If I could I would split the fixture up for parent/child but it doesnt > like that to much either as they use the same model and can only have > one fixture with the right name. > > Thanks for the help!! > -Nick > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
That doesn''t seem to be the case here unfortunatly. Tried changing the ''products_category'' to ''zproducts_category'' and it is acting the same way. (thought it might be in ''reverse sort'' because last i checked p comes before s). I''ve tried changing things around but to no avail. Any other suggestions on this? Or should I file a bug report? It seems pretty easy to reproduce. On 10/16/05, Tom Mornini <tmornini-W/9V78bTXriB+jHODAdFcQ@public.gmane.org> wrote:> The fixtures are loaded in sort-by-name order. > > I ran into this last week. > > There''s already a ticket to address this issue in the future. > > -- > -- Tom Mornini > > On Oct 16, 2005, at 2:02 PM, Nick Stuart wrote: > > > I seem to be having a problem with one of my fixtures and the foreign > > keys with-in. I have a basic setup where the table holds both child > > and parent values, (id, and parent_id). I''m using postgres so I set > > the parent_id to be a foreign key that references id. > > > > If i go through the console, or just using straight SQL I can create > > parents and childs (parents having a parent_id of nil). Whenever I go > > to run the test, however, it always complains that the parent_id of 1 > > does not exist. Heres the problem fixture: > > products_category: > > id: 1 > > name: Products > > description: Products Category > > software_category: > > id: 2 > > parent_id: 1 > > name: Software > > description: Software Category > > > > If I comment out all the child categories then the tests that dont > > look at them pass, but of course the other ones that do fail. The only > > thing I can think of is that its doing inserts in a transaction, and > > thats whats screwing things up. Any other ideas? > > > > If I could I would split the fixture up for parent/child but it doesnt > > like that to much either as they use the same model and can only have > > one fixture with the right name. > > > > Thanks for the help!! > > -Nick > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
I had to turn off transactional fixtures, or it still didn''t work. -- -- Tom Mornini On Oct 17, 2005, at 5:15 AM, Nick Stuart wrote:> That doesn''t seem to be the case here unfortunatly. Tried changing the > ''products_category'' to ''zproducts_category'' and it is acting the same > way. (thought it might be in ''reverse sort'' because last i checked p > comes before s). > > I''ve tried changing things around but to no avail. Any other > suggestions on this? Or should I file a bug report? It seems pretty > easy to reproduce. > > On 10/16/05, Tom Mornini <tmornini-W/9V78bTXriB+jHODAdFcQ@public.gmane.org> wrote: > >> The fixtures are loaded in sort-by-name order. >> >> I ran into this last week. >> >> There''s already a ticket to address this issue in the future. >> >> -- >> -- Tom Mornini >> >> On Oct 16, 2005, at 2:02 PM, Nick Stuart wrote: >> >> >>> I seem to be having a problem with one of my fixtures and the >>> foreign >>> keys with-in. I have a basic setup where the table holds both child >>> and parent values, (id, and parent_id). I''m using postgres so I set >>> the parent_id to be a foreign key that references id. >>> >>> If i go through the console, or just using straight SQL I can create >>> parents and childs (parents having a parent_id of nil). Whenever >>> I go >>> to run the test, however, it always complains that the parent_id >>> of 1 >>> does not exist. Heres the problem fixture: >>> products_category: >>> id: 1 >>> name: Products >>> description: Products Category >>> software_category: >>> id: 2 >>> parent_id: 1 >>> name: Software >>> description: Software Category >>> >>> If I comment out all the child categories then the tests that dont >>> look at them pass, but of course the other ones that do fail. The >>> only >>> thing I can think of is that its doing inserts in a transaction, and >>> thats whats screwing things up. Any other ideas? >>> >>> If I could I would split the fixture up for parent/child but it >>> doesnt >>> like that to much either as they use the same model and can only >>> have >>> one fixture with the right name. >>> >>> Thanks for the help!! >>> -Nick >>> _______________________________________________ >>> Rails mailing list >>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>> http://lists.rubyonrails.org/mailman/listinfo/rails >>> >>> >> >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
I thought they were off by default? no? On 10/17/05, Tom Mornini <tmornini-W/9V78bTXriB+jHODAdFcQ@public.gmane.org> wrote:> I had to turn off transactional fixtures, or it still didn''t work. > > -- > -- Tom Mornini > > > On Oct 17, 2005, at 5:15 AM, Nick Stuart wrote: > > > That doesn''t seem to be the case here unfortunatly. Tried changing the > > ''products_category'' to ''zproducts_category'' and it is acting the same > > way. (thought it might be in ''reverse sort'' because last i checked p > > comes before s). > > > > I''ve tried changing things around but to no avail. Any other > > suggestions on this? Or should I file a bug report? It seems pretty > > easy to reproduce. > > > > On 10/16/05, Tom Mornini <tmornini-W/9V78bTXriB+jHODAdFcQ@public.gmane.org> wrote: > > > >> The fixtures are loaded in sort-by-name order. > >> > >> I ran into this last week. > >> > >> There''s already a ticket to address this issue in the future. > >> > >> -- > >> -- Tom Mornini > >> > >> On Oct 16, 2005, at 2:02 PM, Nick Stuart wrote: > >> > >> > >>> I seem to be having a problem with one of my fixtures and the > >>> foreign > >>> keys with-in. I have a basic setup where the table holds both child > >>> and parent values, (id, and parent_id). I''m using postgres so I set > >>> the parent_id to be a foreign key that references id. > >>> > >>> If i go through the console, or just using straight SQL I can create > >>> parents and childs (parents having a parent_id of nil). Whenever > >>> I go > >>> to run the test, however, it always complains that the parent_id > >>> of 1 > >>> does not exist. Heres the problem fixture: > >>> products_category: > >>> id: 1 > >>> name: Products > >>> description: Products Category > >>> software_category: > >>> id: 2 > >>> parent_id: 1 > >>> name: Software > >>> description: Software Category > >>> > >>> If I comment out all the child categories then the tests that dont > >>> look at them pass, but of course the other ones that do fail. The > >>> only > >>> thing I can think of is that its doing inserts in a transaction, and > >>> thats whats screwing things up. Any other ideas? > >>> > >>> If I could I would split the fixture up for parent/child but it > >>> doesnt > >>> like that to much either as they use the same model and can only > >>> have > >>> one fixture with the right name. > >>> > >>> Thanks for the help!! > >>> -Nick > >>> _______________________________________________ > >>> Rails mailing list > >>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >>> http://lists.rubyonrails.org/mailman/listinfo/rails > >>> > >>> > >> > >> _______________________________________________ > >> Rails mailing list > >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >> http://lists.rubyonrails.org/mailman/listinfo/rails > >> > >> > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Yes, but I mentioned it just in case.
In 0.14 they seem to be on by default, if I understand it correctly.
Additionally, I left out a critical component provided by list member
"Blair Zajac" <blair-szbw9MROnEZWk0Htik3J/w@public.gmane.org>
# Delete the fixtures associated with this test suite in the reverse
# order that they are loaded. Take care to use the database
# connection associated with the fixture, not with the model being
# tested. "Blair Zajac"
<blair-szbw9MROnEZWk0Htik3J/w@public.gmane.org>
def teardown
self.class.fixture_table_names.reverse.each do |table_name|
klass_name = Inflector.classify(table_name.to_s)
if Object.const_defined?(klass_name)
klass = Object.const_get(klass_name)
klass.connection.delete("DELETE FROM #{table_name}",
''Fixture Delete'')
else
ActiveRecord::Base.connection.execute("DELETE FROM #
{table_name}")
end
end
end
--
-- Tom Mornini
On Oct 18, 2005, at 1:57 PM, Nick Stuart wrote:
> I thought they were off by default? no?
>
> On 10/17/05, Tom Mornini
<tmornini-W/9V78bTXriB+jHODAdFcQ@public.gmane.org> wrote:
>
>> I had to turn off transactional fixtures, or it still didn''t
work.
>>
>> --
>> -- Tom Mornini
>>
>>
>> On Oct 17, 2005, at 5:15 AM, Nick Stuart wrote:
>>
>>
>>> That doesn''t seem to be the case here unfortunatly. Tried
>>> changing the
>>> ''products_category'' to
''zproducts_category'' and it is acting the
>>> same
>>> way. (thought it might be in ''reverse sort''
because last i checked p
>>> comes before s).
>>>
>>> I''ve tried changing things around but to no avail. Any
other
>>> suggestions on this? Or should I file a bug report? It seems pretty
>>> easy to reproduce.
>>>
>>> On 10/16/05, Tom Mornini
<tmornini-W/9V78bTXriB+jHODAdFcQ@public.gmane.org> wrote:
>>>
>>>
>>>> The fixtures are loaded in sort-by-name order.
>>>>
>>>> I ran into this last week.
>>>>
>>>> There''s already a ticket to address this issue in the
future.
>>>>
>>>> --
>>>> -- Tom Mornini
>>>>
>>>> On Oct 16, 2005, at 2:02 PM, Nick Stuart wrote:
>>>>
>>>>
>>>>
>>>>> I seem to be having a problem with one of my fixtures and
the
>>>>> foreign
>>>>> keys with-in. I have a basic setup where the table holds
both
>>>>> child
>>>>> and parent values, (id, and parent_id). I''m using
postgres so I
>>>>> set
>>>>> the parent_id to be a foreign key that references id.
>>>>>
>>>>> If i go through the console, or just using straight SQL I
can
>>>>> create
>>>>> parents and childs (parents having a parent_id of nil).
Whenever
>>>>> I go
>>>>> to run the test, however, it always complains that the
parent_id
>>>>> of 1
>>>>> does not exist. Heres the problem fixture:
>>>>> products_category:
>>>>> id: 1
>>>>> name: Products
>>>>> description: Products Category
>>>>> software_category:
>>>>> id: 2
>>>>> parent_id: 1
>>>>> name: Software
>>>>> description: Software Category
>>>>>
>>>>> If I comment out all the child categories then the tests
that dont
>>>>> look at them pass, but of course the other ones that do
fail. The
>>>>> only
>>>>> thing I can think of is that its doing inserts in a
>>>>> transaction, and
>>>>> thats whats screwing things up. Any other ideas?
>>>>>
>>>>> If I could I would split the fixture up for parent/child
but it
>>>>> doesnt
>>>>> like that to much either as they use the same model and can
only
>>>>> have
>>>>> one fixture with the right name.
>>>>>
>>>>> Thanks for the help!!
>>>>> -Nick
>>>>> _______________________________________________
>>>>> Rails mailing list
>>>>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>>>>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Rails mailing list
>>>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>>>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Rails mailing list
>>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>>
>>>
>>
>> _______________________________________________
>> Rails mailing list
>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>