6👍
✅
From Django’s source code below, it is almost the same. Both methods call the _chain
method. With filter
, you create a Q
object without any children, but the overhead is not much.
Using all
is nonetheless preferable as it is avoiding unnecessary code to be executed.
def all(self):
"""
Return a new QuerySet that is a copy of the current one. This allows a
QuerySet to proxy for a model manager in some cases.
"""
return self._chain()
def filter(self, *args, **kwargs):
"""
Return a new QuerySet instance with the args ANDed to the existing
set.
"""
return self._filter_or_exclude(False, *args, **kwargs)
def _filter_or_exclude(self, negate, *args, **kwargs):
if args or kwargs:
assert self.query.can_filter(), \
"Cannot filter a query once a slice has been taken."
clone = self._chain()
if negate:
clone.query.add_q(~Q(*args, **kwargs))
else:
clone.query.add_q(Q(*args, **kwargs))
return clone
11👍
Yes, both will perform the same in a database point of view once you are not passing any arguments on the filter. The filter will execute more processing steps, once it needs to check if you passed arguments or not, but the difference will be very little.
In this case, I suppose you should use the all() instead of filter just to make your code more clear about what are you doing.
Source:stackexchange.com