>
> Why shouldn't test_obj be in that query result? test_obj has a m2m with
> int_value 10 and a m2m (although another one) with char_value bar
>
The assertions are just saying what the current behavior of the ORM *is*.
Under the hood, it's because Q(m2ms__int_value=10) &
Q(m2ms__char_value='b
I didn't read closely enough to completely understand but i'll mention that
Q object behavior is one of the trickiest bits of the ORM. Some of the
relevant reading might be:
* https://github.com/django/django/pull/4385
* https://github.com/django/django/pull/6005
Anssi would be the person to ta
assert test_obj not in TestObj.objects.filter(Q(m2ms__int_value=10) &
Q(m2ms__char_value='bar'))
Why shouldn't test_obj be in that query result? test_obj has a m2m with
int_value 10 and a m2m (although another one) with char_value bar
On Sat, Feb 13, 2016 at 7:45 PM, Lucas Wiman wrote:
> I'm wo
I'm working on the django-predicate library, which defines in-memory
evaluation semantics for Q objects. The eventual goal is to precisely match
the behavior of the ORM on the subset of supported lookup types. Yesterday,
I noticed a bug in that library, where there was a mismatch with the
behav
4 matches
Mail list logo
