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 blocker.
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 W
Aymeric,
No problem. Thanks for the replies. I just created the ticket @
https://code.djangoproject.com/ticket/20666
On Wednesday, June 26, 2013 2:27:03 AM UTC-4, Aymeric Augustin wrote:
>
> Thanks for taking the time to check. Based on Russell's message, I think
> that's a bug, but I'm not sur
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 happen in 1.5, but the err
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 being
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 bug affects all versions o
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 s
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 7:24
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 methods
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 models
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. I
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 because
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 Thing(mo
13 matches
Mail list logo