This repository has been archived by the owner on Feb 7, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 53
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
simplify VersionedQuerySet 1.6 and 1.7 compatible __init__
- Loading branch information
Showing
1 changed file
with
2 additions
and
6 deletions.
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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,7 +14,6 @@ | |
|
||
import copy | ||
import datetime | ||
from django import VERSION | ||
from django.core.exceptions import SuspiciousOperation, MultipleObjectsReturned, ObjectDoesNotExist | ||
from django.db.models.constants import LOOKUP_SEP | ||
|
||
|
@@ -151,11 +150,8 @@ class VersionedQuerySet(QuerySet): | |
|
||
query_time = None | ||
|
||
def __init__(self, model=None, query=None, using=None, hints=None): | ||
if VERSION >= (1, 7): # Ensure the correct constructor for Django >= v1.7 | ||
super(VersionedQuerySet, self).__init__(model, query, using, hints) | ||
else: # For Django 1.6, take the former constructor | ||
super(VersionedQuerySet, self).__init__(model, query, using) | ||
def __init__(self, *args, **kwargs): | ||
super(VersionedQuerySet, self).__init__(*args, **kwargs) | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
brki
Author
Contributor
|
||
|
||
self.related_table_in_filter = set() | ||
"""We will store in it all the tables we have being using in while filtering.""" | ||
|
@brki are you sure this will work fine? I had a problem on a project recently were I was passing a dictionary to a function using kwargs. But the kwargs content was build by fetching data from another source and I was not controlling what could go inside it. Everything was fine till one day another extra key/value pair made it into the dictionary. The called function was not expecting such a parameter and hence failed.
I think that here we could have the same situation. Someone could call init providing a 'hints' parameter. And in case we run on Django 1.6 we will call the other init with this extra parameter and I think it will blow of.
But I might be wrong, did you do the test on 1.6 passing a 'hints' parameter value?