Potential issue with field.queryset._result_cache persisting

[Luke Benstead]

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 :)