id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
27937	Potential issue with field.queryset._result_cache persisting	Luke Benstead	nobody	"Hi,

I'm currently working on porting Djangae to work with Django 1.11. As part of our test suite we run a number of Django tests which occasionally show up assumptions in the tests which don't hold true on the Google App Engine datastore, one common one is that IDs of objects created in tests will be sequential.

The last remaining test failure I have is a sporadic failure in `tests.model_forms.tests.LimitChoicesToTests` depending on the order in which the tests are run, either `test_limit_choices_to_callable_for_fk_rel` or `test_limit_choices_to_callable_for_m2m_rel` fails. 

Here's one of those tests:

{{{
    def test_limit_choices_to_callable_for_fk_rel(self):
        """"""
        A ForeignKey can use limit_choices_to as a callable (#2554).
        """"""
        stumpjokeform = StumpJokeForm()
        self.assertSequenceEqual(stumpjokeform.fields['most_recently_fooled'].queryset, [self.threepwood])
}}}

The reason for the failure, is that immediately after `StumpJokeForm()` is instantiated (by the second of the two tests) the field's `queryset._result_cache` is already populated, holding an instance which no longer exists in the database as it was flushed between tests. It's as if the field's queryset is persisting between form instantiations, and between tests. It looks likely that this wouldn't show up in a normal Django test run because IDs are sequential there and so the IDs match when testing the assertion.

I'm always unsure about reporting bugs like this because Djangae has to do so much ""weird"" stuff to work it's possible it's something that we're doing but in this case I don't think it is. If it is something we're doing then I apologise in advance :)

"	Bug	closed	Forms	1.11	Normal	duplicate			Unreviewed	0	0	0	0	0	0