New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Django 1.9, 1.10, and 1.11 upgrades #125
Merged
Merged
Changes from 1 commit
Commits
Show all changes
27 commits
Select commit
Hold shift + click to select a range
bfca2e2
add newer django+python to tox+travis
tobiasmcnulty 004261f
convert assigned lambda funcs to def statements
tobiasmcnulty 3cf88d7
Merge branch 'master' into tox-updates
tobiasmcnulty 23b28c6
fix flake8 errors
tobiasmcnulty f12a36c
make travis use tox
tobiasmcnulty d6c527e
specify only one python since tox does that now
tobiasmcnulty aed2def
pass TRAVIS environment variable into tox environment
tobiasmcnulty 615585b
don't run flake8 as part of travis, use tox
tobiasmcnulty dcc81ab
Update tox and travis
vkurup 2668094
Include flake8 on travis
vkurup d450cff
Workaround Travis bug
vkurup 77d21e8
Try to get coverage working
vkurup 79281be
Remove support for Python < 2.7, Django < 1.8
vkurup 36589e9
Remove obsolete package
vkurup f6839e4
Django 1.9 support
vkurup 3b562d4
Django 1.10 support
vkurup b7295ff
Tell Travis to test 1.10
vkurup 6a547d8
Django 1.11 support
vkurup 7bd4f77
Cleanup and docs updates
vkurup 24c9779
Add tests for failure when running .values() or .values_list()
vkurup f98e32f
Typo
vkurup 4f1fb8e
Attempt to tease out Django 1.8 differences
vkurup 085bf35
enable --keepdb for faster test runs
tobiasmcnulty 52d4ea6
try to simplify Django 1.8/Django 1.11 compatibility
tobiasmcnulty c220d61
Merge pull request #1 from tobiasmcnulty/django-upgrades
vkurup 096f2b2
Minor doc updates
vkurup 251e5e6
Bump version for release
vkurup File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this change will cause a server-side cursor to be used for
_fetch_all
(if not globally disabled viaDISABLE_SERVER_SIDE_CURSORS
) on Django 1.11.1+ due two these lines:I think we need to make sure
_fetch_all()
still usesself._iterable_class()
directly rather thanself.iterator()
on Django 1.11+, perhaps via something along the lines of the following:iterator()
logic into a separate method, e.g.,_iterate_on(iterable)
_fetch_all()
, calllist(self._iterate_on(iter(self._iterable_class(self))))
for Django 1.11+ orlist(self._iterate_on(self.iterator()))
for older Djangos (_iterable_class
unfortunately does not exist in Django 1.8).iterator()
, simply returnself._iterate_on(super(CachingQuerySet, self).iterator())
Does that seem crazy? What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or better yet, rather than check the version directly, use duck typing as you already did here: 24c9779#diff-76150a51cd21d8d6b30aaaab22c7f114R179
_fetch_all()
anditerator()
are unchanged between Django 1.9-1.10, so it should be safe to useself._iterable_class
directly in those versions (in addition to Django 1.11)_fetch_all()
:iterator()
: