FYI, I was finally able to resolve this. I had an assumption that
TestCase's began with a freshly created database between TestCase classes.
I asserted this in _fixture_setup() and found that assumption to be false.
Upon further research I found a setUpClass() in another TestCase that
e way, Django 1.7 is no longer supported. Please make sure you can
> reproduce the issue on Django master so we don't spend time debugging
> issues that have since been fixed.
>
> On Wednesday, May 4, 2016 at 7:13:42 PM UTC-4, Rich Rauenzahn wrote:
>>
>>
>> I'm in the
I'm in the middle of trying to track down a problem with loading fixtures
during unit tests -- I'm hesitant to call it a bug in Django 1.7, but the
inconsistent behavior is really stumping me.
Essentially I've made a fixture via
manage dumpdata --indent=3 -e sessions -e admin -e
On Friday, April 29, 2016 at 11:00:37 AM UTC-7, Aymeric Augustin wrote:
>
> Hi Rich,
>
> On 29 Apr 2016, at 19:52, Rich Rauenzahn <rrau...@gmail.com >
> wrote:
>
>
> I see now that I need to provide a sentinel value --
> BOO=True,VAL=, or manually create additi
On Friday, April 29, 2016 at 2:16:45 AM UTC-7, Anssi Kääriäinen wrote:
>
> If you really, really want an unique index that allows just a single
> value, you might want to try unique index on (a, b, c) where c is not
> null, and another unique index on (a, b) where c is null. That might
> give
On Friday, April 29, 2016 at 12:51:31 AM UTC-7, Florian Apolloner wrote:
>
>
> I am not against a note in the docs, but I find the fact that nulls are
> not "unique" and can exist in an index more than once very useful (fwiw
> ordering after a column with null can also be interesting across
>
I just got bitten by this today, finding a duplicate row where I didn't
expect one. I haven't been able to find an existing Django bug.
It's a popular topic on stack overflow:
http://stackoverflow.com/questions/17510261/django-unique-together-constraint-failure
