Re: Circularly dependent fixtures fail with Postgres 9.2

If you can confirm that the problem exists on 1.6, but doesn't exist on 1.5, then yes, it is a release blocker. However, as I understand, you were reporting the same problem in 1.5. If it's the same problem, or a different error rising from the same root cause, then no, it isn't a release

Re: Circularly dependent fixtures fail with Postgres 9.2

Aymeric, Somebody (anonymous) said in the ticket that they had a problem in 1.6 and not in 1.5. I had a similar error on both, but there might be unrelated issues in both versions. Would that make it a release blocker? Sorry for not posting a reply on here sooner (the beta release today). On

Re: Circularly dependent fixtures fail with Postgres 9.2

Thanks for taking the time to check. Based on Russell's message, I think that's a bug, but I'm not sure why it happens. Could you file a ticket in the tracker, so we don't forget about it? Thank you, -- Aymeric. On 26 juin 2013, at 02:43, Yo-Yo Ma wrote: > It does

Re: Circularly dependent fixtures fail with Postgres 9.2

Hi Aymeric, It does happen in 1.5, but the error is somehow slightly different (no traceback in 1.5 to find the root cause). I have 2 fields on the order model pointing to the address model. I included only the one in my above example because it was consistently the culprit (likely due to

Re: Circularly dependent fixtures fail with Postgres 9.2

Would you mind checking if the bug occurs in Django 1.5? If it doesn't, it's a regression introduced by the new transaction management in Django 1.6, and it's a release blocker. -- Aymeric. On 25 juin 2013, at 22:30, Yo-Yo Ma wrote: > I should actually note, this

Re: Circularly dependent fixtures fail with Postgres 9.2

I should actually note, this bug affects all versions of Postgres, and presumably all other supported RDBMSs as well. On Sunday, June 23, 2013 7:35:45 PM UTC-4, Yo-Yo Ma wrote: > > Minor correction: I placed Atomic.__exit__ to verify - the transaction is > commited every time *starting* on the

Re: Circularly dependent fixtures fail with Postgres 9.2

Minor correction: I placed Atomic.__exit__ to verify - the transaction is commited every time *starting* on the second object (the third stack printed in the previous post) - it happens at https://github.com/django/django/blob/master/django/db/transaction.py#L288. On Sunday, June 23, 2013

Re: Circularly dependent fixtures fail with Postgres 9.2

Hi again Russell, I did a little digging. I'm not sure, but I may have uncovered the problem. A transaction block (using `commit_on_success_unless_managed`) is entered and exited during each fixture object loaded, due to the calls to the aforementioned method that exist in various model

Re: Circularly dependent fixtures fail with Postgres 9.2

Pardon one typo: I meant `python manage.py loaddata test_data` in my previous post. On Friday, June 21, 2013 4:32:33 PM UTC-4, Yo-Yo Ma wrote: > > Hi Russel, > > Thanks for taking the time to explain that. I tried that same day to > reproduce the issue in a testing env with the simplified

Re: Circularly dependent fixtures fail with Postgres 9.2

Hi Russel, Thanks for taking the time to explain that. I tried that same day to reproduce the issue in a testing env with the simplified models I typed above, but my hosting provider had some erroneous networking nonsense that ruined my test after I spent a couple hours setting everything up.

Re: Circularly dependent fixtures fail with Postgres 9.2

Circular dependencies *shouldn't* be a problem on PostgreSQL because all constraints are set DEFERABLE INITIALLY DEFERRED; that means no constrain checks should be performed are performed until the transaction boundary, so all circular references shouldn't be a problem. Ticket #3615 exists

Circularly dependent fixtures fail with Postgres 9.2

There doesn't appear to be a way to load fixtures from JSON (using Postgres - works fine in sqlite3) for the following models: class Collection(models.Model): main_thing = models.OneToOneField( 'things.Thing', null=True, on_delete=models.SET_NULL ) class