Fixed#32398--Fixed negated annotation filter on build_filter #14065

baidoosik · 2021-03-01T15:34:30Z

I fixed the reported bug. but when the driving table has left join, I can't handle it right now. it is difficult on the current structure.
(this code -> self.alias_map[join_list[-1]].join_type == LOUTER))
If there are any issues, please tell me. and frankly, I don't know where is the good place to put the test code...

jacobtylerwalls · 2021-03-01T20:38:16Z

tests/queries/test_query.py

@@ -91,6 +93,35 @@ def test_negated_nullable(self):
        self.assertIsInstance(lookup, IsNull)
        self.assertEqual(lookup.lhs.target, Item._meta.get_field('modified'))

+    def test_negated_annotation_nullable(self):
+        query = Query(Item.objects.annotate(year=ExtractYear('modified')).exclude(modified='2021'))


Greetings, and thanks for your patch. The format of 2021 here is causing a test failure. To make this easier to review could you correct it? Thanks.

@jacobtylerwalls I added other test cases. if another test cases are needed, tell me.

@jacobtylerwalls could you retry this test 'Tests / JavaScript tests (pull_request) '? I don't know why it was failed.

jacobtylerwalls

Hi @baidoosik, thanks for getting started here. Don't worry about the JS test -- it will rerun when you push again. Speaking of which--it's time to rewrite your branch history. Can you rebase and squash your commits to just two, one for the new test that increases coverage, and one for your patch and regression test?

jacobtylerwalls · 2021-03-02T15:26:16Z

tests/queries/test_query.py

+    def test_equality_with_negated_nullable(self):
+        # nullable field
+        self.assertNotEqual(
+            Item.objects.exclude(modified__year='2021').values('id').query,
+            Item.objects.annotate(year=ExtractYear('modified')).exclude(year='2021').values('id').query,
+        )
+        # not nullable field
+        self.assertNotEqual(
+            Item.objects.exclude(created__year='2021').values('id').query,
+            Item.objects.annotate(year=ExtractYear('created')).exclude(year='2021').values('id').query,
+        )


This test passes without applying your patch -- we like tests that increase coverage to be in separate commits. (what if we have to revert the new behavior? we can keep the test increasing coverage.)

I want to check this. I will fix this.
self.assertEqual(
str(Item.objects.exclude(modified__year='2021').values('id').query),
str(Item.objects.annotate(year=ExtractYear('modified')).exclude(year='2021').values('id').query),
)

jacobtylerwalls · 2021-03-02T15:30:02Z

tests/queries/test_query.py

+    def test_negated_nullable_with_excluding_on_annotation(self):
+        # nullable field
+        query = str(Item.objects.annotate(year=ExtractYear('modified')).exclude(year='2021').values('id').query)
+        self.assertTrue('IS NOT NULL' in query)


I think evaluating the result of a query (such as with assertQuerysetEqual) is much better than checking whether there's a random IS NOT NULL somewhere in the SQL. This would involve creating some objects.

@jacobtylerwalls okay. Thanks for your review.

jacobtylerwalls · 2021-03-02T15:32:17Z

django/db/models/sql/query.py

+                target = targets[0].target
+                lookup_type = condition.lookup_name
+                clause.add(condition, AND)
+                if current_negated and lookup_type != 'isnull' and condition.rhs is not None \
+                        and self.is_nullable(target):
+                    # The condition added here will be SQL like this:
+                    # NOT (col IS NOT NULL), where the first NOT is added in
+                    # upper layers of code. The reason for addition is that if col
+                    # is null, then col != someval will result in SQL "unknown"
+                    # which isn't the same as in Python. The Python None handling
+                    # is wanted, and it can be gotten by
+                    # (col IS NULL OR col != someval)
+                    #   <=>
+                    # NOT (col IS NOT NULL AND col = someval).
+                    lookup_class = target.get_lookup('isnull')
+                    col = self._get_col(target, target, alias)
+                    clause.add(lookup_class(col, False), AND)


Have you explored a way to resolve the DRY issues here?

Originally i try to use the below logic for checking negated null column.

if current_negated and (lookup_type != 'isnull' or condition.rhs is False) and condition.rhs is not None: require_outer = True if lookup_type != 'isnull': # The condition added here will be SQL like this: # NOT (col IS NOT NULL), where the first NOT is added in # upper layers of code. The reason for addition is that if col # is null, then col != someval will result in SQL "unknown" # which isn't the same as in Python. The Python None handling # is wanted, and it can be gotten by # (col IS NULL OR col != someval) # <=> # NOT (col IS NOT NULL AND col = someval). if ( self.is_nullable(targets[0]) or self.alias_map[join_list[-1]].join_type == LOUTER ): lookup_class = targets[0].get_lookup('isnull') col = self._get_col(targets[0], join_info.targets[0], alias) clause.add(lookup_class(col, False), AND) # If someval is a nullable column, someval IS NOT NULL is # added. if isinstance(value, Col) and self.is_nullable(value.target): lookup_class = value.target.get_lookup('isnull') clause.add(lookup_class(value, False), AND)

but in my view, other logic on below that code is not designed for reffed_expression.
so, I can't resolve DRY issues.
If you have any good idea, please tell me.

try: join_info = self.setup_joins( parts, opts, alias, can_reuse=can_reuse, allow_many=allow_many, reuse_with_filtered_relation=reuse_with_filtered_relation, ) # Prevent iterator from being consumed by check_related_objects() if isinstance(value, Iterator): value = list(value) self.check_related_objects(join_info.final_field, value, join_info.opts) # split_exclude() needs to know which joins were generated for the # lookup parts self._lookup_joins = join_info.joins except MultiJoin as e: return self.split_exclude(filter_expr, can_reuse, e.names_with_path)

jacobtylerwalls · 2021-03-03T16:49:10Z

django/test/testcases.py

+    def assertQueryEqual(self, query1, query2, msg=None):
+        """
+        Assert that two queries generate same sql. .
+        The arguments must be valid Query.


Sorry I didn't provide a better tip -- I was talking about Django's own testing tool for this: https://docs.djangoproject.com/en/dev/topics/testing/tools/#django.test.TransactionTestCase.assertQuerysetEqual

Have a look at the other test cases that use this test method.

@jacobtylerwalls okay! Thanks!

@jacobtylerwalls

I wanna make two testcases.

for proving case about the reported issue.
it is enough to write code like below, right?
self.assertEqual(
str(Item.objects.exclude(modified__year='2021').values('id').query),
str(tem.objects.annotate(year=ExtractYear('modified')).exclude(year='2021').values('id').query)
)

check the IS NOT NULL includes or not in about each cases.
about this cases I will use 'TransactionTestCase.assertQuerysetEqual' this.

Is it okay?

Go for it. Another reviewer may let you know if it looks unnecessary to test the raw SQL, but we do have other tests that do this:

django/tests/queries/tests.py

Lines 3137 to 3139 in a948d9d

def test_null_join_demotion(self):

qs = ModelA.objects.filter(Q(b__name__isnull=False) & Q(b__name__isnull=True))

self.assertIn(' INNER JOIN ', str(qs.query))

I was just trying to encourage you to create and evaluate querysets. 👍🏻

'TransactionTestCase.assertQuerysetEqual' compare query result(return data from db) with iterable. that is not test i want. because i wanna check to include 'IS NOT NULL' or not according to each condition. give me your opinion :)

I'm just one voice -- if other reviewers think testing the raw SQL is fine, we can roll on. Sure, let's get your test of the raw SQL in place and then hear from other reviewers.

What makes me nervous about only verifying the raw SQL instead of checking that the query got the right objects from the db is that these queries are complex -- how do I know the IS NOT NULL is in the right place? Won't there be a false negative if there's an IS NOT NULL on some other column? Then to review your patch I have to print out the raw SQL and check it myself, if you get where I'm going.

@jacobtylerwalls I think so, too.

I added only case1. I think it's enough to prove the issue. if you or other reviewers think we need more tests, tell me.

jacobtylerwalls · 2021-03-03T17:33:16Z

django/db/models/sql/query.py

+                if current_negated and lookup_type != 'isnull' and condition.rhs is not None \
+                        and self.is_nullable(target):


Avoid line continuation characters.

Suggested change

if current_negated and lookup_type != 'isnull' and condition.rhs is not None \

and self.is_nullable(target):

if (

current_negated and

lookup_type != 'isnull' and

condition.rhs is not None and

self.is_nullable(target)

):

Thanks! I updated.

This appears to have resurfaced.

Yes. I changed this by felixxm suggestion.

Oh I just meant code style. The suggestion didn't have a backslash, and we avoid them in Django.

ah okay! Thanks!

felixxm

@baidoosik Thanks for this patch 👍 I left comments.

felixxm · 2021-03-04T06:20:16Z

tests/queries/test_query.py

+        self.assertEqual(
+            str(Item.objects.exclude(created__year='2021').values('id').query),
+            str(Item.objects.annotate(year=ExtractYear('created')).exclude(year='2021').values('id').query),
+        )


Comparing raw queries is the last resort, in this case we should be able to create a queryset that doesn't return the correct results without a fix:

self.assertCountEqual( queryset, [....], )

felixxm · 2021-03-04T06:22:07Z

tests/queries/test_query.py

+        # nullable field
+        self.assertEqual(
+            str(Item.objects.exclude(modified__year='2021').values('id').query),
+            str(Item.objects.annotate(year=ExtractYear('modified')).exclude(year='2021').values('id').query),


ExtractYear() is not important for this test, I would use a simpler function, e.g. Lower().

felixxm · 2021-03-04T06:26:39Z

django/db/models/sql/query.py

+            targets = reffed_expression.get_source_expressions()
+            if targets and isinstance(targets[0], Col):
+                target = targets[0].target
+                lookup_type = condition.lookup_name
+                clause.add(condition, AND)
+                if (
+                    current_negated and
+                    lookup_type != 'isnull' and
+                    condition.rhs is not None and
+                    self.is_nullable(target)
+                ):
+                    # The condition added here will be SQL like this:
+                    # NOT (col IS NOT NULL), where the first NOT is added in
+                    # upper layers of code. The reason for addition is that if col
+                    # is null, then col != someval will result in SQL "unknown"
+                    # which isn't the same as in Python. The Python None handling
+                    # is wanted, and it can be gotten by
+                    # (col IS NULL OR col != someval)
+                    #   <=>
+                    # NOT (col IS NOT NULL AND col = someval).
+                    lookup_class = target.get_lookup('isnull')
+                    col = self._get_col(target, target, alias)
+                    clause.add(lookup_class(col, False), AND)
+            return clause, ()


We can try to refactor existing code and add some internal hook instead of having similar (identical?) logic in two places.

Also, I don't think it's a complete solution as annotations on the LHS still don't work properly, see failing test:

def test_exclude_nullable_fields_annotation(self): from django.db.models.functions import Abs number = Number.objects.create(num=1, other_num=1) Number.objects.create(num=2, other_num=2, another_num=2) self.assertSequenceEqual( Number.objects.annotate(x=Abs('another_num')).exclude(other_num=F('x')), [number], ) self.assertSequenceEqual( Number.objects.annotate(x=Abs('another_num')).exclude(num=F('x')), [number], )

@felixxm in my view, below test code is our expected result.

def test_exclude_nullable_fields_annotation(self): from django.db.models.functions import Abs number = Number.objects.create(num=1, other_num=1) Number.objects.create(num=2, other_num=2, another_num=2) self.assertSequenceEqual( Number.objects.annotate(x=Abs('another_num')).exclude(other_num=F('x')), [], ) self.assertSequenceEqual( Number.objects.annotate(x=Abs('another_num')).exclude(num=F('x')), [], )

Because I expect that query makes like below SQL. I think another_sum is nullable, so need to add is not null.
it means return 0 rows.

-- First Queryset SELECT num, other_num, another_num FROM number WHERE NOT(another_num IS NOT NULL AND other_num = abs(another_sum)) -- Second Queryset SELECT num, other_num, another_num FROM number WHERE NOT(another_num IS NOT NULL AND num = abs(another_sum))

Let me know if I'm misunderstanding.

@felixxm At the first, I wanna reuse existing code but I can't. Because for reusing that code, we have to use some code such as self.setup_joins, self.trim_joins. but setup_joins is not designed for reffed_expression.(just my opinion, as you know that this is my second fix, so I may not understand the code because I am not familiar with it yet.)

If you have some tip about this, please give me. i also wanna improve this.

@felixxm in my view, below test code is our expected result.

No, it's not. 1 != NULL so why it's expected that number is excluded? see 512da9d and ticket-23797 for more details.

@felixxm You're right. but it seems to fail in the 'master' branch, too. and that query is not used changed code.

my changs affect when LHS is annotation field and RHS is not field.

my changs affect when LHS is annotation field and RHS is not field.

I know, but this is also an issue with nullable annotation so we should fix it in this PR. If it is a different branch in build_filter() then we have another reason to add some hook.

@felixxm Ok. it makes sense. I will check this also.

felixxm · 2021-03-04T06:32:24Z

tests/queries/test_query.py

@@ -165,6 +165,18 @@ def test_equality(self):
            Author.objects.filter(Q(item__name='foo')).query,
        )

+    def test_equality_with_negated_nullable(self):


Please move this test to tests.queries.tests.ExcludeTests.

@felixxm okay! Thanks for review.

baidoosik · 2021-03-21T13:17:10Z

@felixxm I reflected your feedback. I try to refactor the existing code.

baidoosik · 2021-03-25T00:54:36Z

@felixxm When you have time, please review this :)

jacobtylerwalls · 2021-03-25T01:01:36Z

Don't forget to keep the "Needs..." flags on the ticket up to date, otherwise your PR won't be visible in the review queue.

baidoosik · 2021-03-25T01:27:33Z

@jacobtylerwalls could you know me how to keep the 'Need...' flags?

jacobtylerwalls · 2021-03-25T01:31:35Z

The checkboxes on the ticket. Just log in to Trac (presumably with your GitHub creds) and you'll see the last action on the ticket was when a reviewer used those boxes to indicate tests and improvements still needed. If you're caught up on review feedback, it's time to let people know on the ticket by unsetting the flags.

jacobtylerwalls · 2021-03-25T01:33:10Z

Oh sorry, didn't see you included a screenshot. Uncheck "needs tests" and "patch needs improvement" and save your changes.

baidoosik · 2021-03-25T01:33:20Z

@jacobtylerwalls Big Thanks!!

baidoosik · 2021-03-30T10:37:45Z

@jacobtylerwalls I think i seem to miss something.(to receive review) If you know about this, please let me know.

felixxm · 2021-03-30T10:42:23Z

@baidoosik Thanks for updates 👍 You didn't miss anything. There are ~30 PRs waiting for a review, please be patient.

baidoosik · 2021-03-30T10:44:44Z

@felixxm Sorry I didn't rush you. It was my first time to open source, so I misunderstood because I didn't know the process well! Thank you for your answer!!

felixxm

@baidoosik Thanks for updates 👍 I think we should start from adding Expression.nullable in a separate PR. Please check my comments.

felixxm · 2021-05-19T08:05:13Z

django/db/models/sql/query.py

+def get_col_from_expression(expression):
+    # get Col from expression
+    targets = expression.get_source_expressions()
+    if targets and isinstance(targets[0], Col):
+        return targets[0]
+    else:
+        return None


I don't think that it will work in all cases, you could use _get_cols() but it doesn't give you much. We need to know whether an expression is nullable or not, so we cannot take only columns into account. Some expressions are non-nullable even if all the columns passed are.

Simon proposed to add a nullable to the BaseExpression (see #11600 (comment)), it would help solving multiple issues (e.g. ticket-25946, ticket-29291) and fits perfectly with this patch. Can you prepare a patch in advance with a new nullable property?

@felixxm What you mean is to fix this bug after proceeding with inserting nullable property first?

@felixxm Okay. I will try to add nullable to the BaseExpression.

@felixxm What you mean is to fix this bug after proceeding with inserting nullable property first?

Yes.

@felixxm Currently i'm trying to add a nullable to BaseExpression.

I think there are two cases in this situation.

Expression which depends on the column.

ex) ExtractYear('created_at') -> depends on 'create_at' field is nullable or not.

Expression which doesn't depends on 'column'.

ex) Subquery -> it's always can be null.

I think I have to divide two cases. how about your opinion?

I saw your comment in the previous PR.

This flag should be set properly for all expressions, e.g. in `Col` should contain the same logic as in is_nullable(), many text functions are not nullable on Oracle because it interprets empty strings as NULL's, e.g. MD5, Concat() is not nullable, etc.

Do I need to check all of the expressions? and if we need to check column, we have to add is_nullable() function, right?

felixxm · 2021-05-19T08:17:53Z

django/db/models/sql/query.py

+                target = col.target
+            else:
+                return clause, ()
+        else:


I really don't like that we increase indentation here, it make code less readable, and it's complicated even without this 😞 We could reduce the number of changes significantly with:

if reffed_expression: condition = self.build_lookup(lookups, reffed_expression, value) clause.add(condition, AND) # When col is nullable, add IS NOT NULL. col = self._gen_cols(reffed_expression) if col: lookup_type = condition.lookup_name target = col.target if current_negated and (lookup_type != 'isnull' or condition.rhs is False) and condition.rhs is not None and self.is_nullable(target): lookup_class = target.get_lookup('isnull') col = self._get_col(target, target, alias) clause.add(lookup_class(col, False), AND) return clause, ()

and reverting related adjustments.

@felixxm Thank you for reviewing. When you said above, we also have to handle when reffed_expression is 'Subquery' or some expressions.

Can we add a test for this case? Currently all tests work with my proposition.

@felixxm
It doesn't work when reffed_expression is the subquery.
below case is failed.

def test_exclude_nullable_subquery_annotation(self): number = Number.objects.create(num=1, other_num=1) subquery_with_null = Subquery(Number.objects.filter(num=1).values('another_num')[:1]) self.assertSequenceEqual( Number.objects.annotate(current_num=subquery_with_null).exclude(current_num=1), [number] )

Ran 1 test in 0.005s

I updated the code according to your suggestion. my test case(for ticket-32864) doesn't work. if there is any missing point, please tell me. and many errors occurred with "target = col.target
AttributeError: 'generator' object has no attribute 'target'".

I tried to handle when reffed_expression is the subquery. but so many other tests are still failed with AttributeError: 'generator' object has no attribute 'target'".

FYI I ran into the same issue of AttributeError: 'generator' object has no attribute 'target'". with this test checking if this PR fixed the issue when using exclude with an alias (flagged up in duplicate ticket-32896):

# ExcludeTests def test_exclude_aliased_nullable_fields(self): number = Number.objects.create(num=1, other_num=1) Number.objects.create(num=2, other_num=2, another_num=2) qs = Number.objects.alias(aliased_num=F('num')) self.assertSequenceEqual( qs.exclude(another_num=F('aliased_num')), [number], ) self.assertSequenceEqual( qs.exclude(aliased_num=F('another_num')), [number], )

felixxm · 2021-05-19T08:23:59Z

Can we also add a test for a nullable subquery annotation (see ticket-32684 that was marked as a duplicate)?

nessita · 2023-05-12T19:38:22Z

Hello @baidoosik! I'm doing some PR cleanup. Would you have time to keep working on this? Specifically, if you could rebase onto the latest main, and also resolve conflicts, that would be great. I can then try to push further the review process, since it seems quite advanced already.

Thank you!

baidoosik · 2023-05-21T07:50:14Z

@nessita Hi ~! sorry for late response. i think it's hard to keep this PR. You can close this. i will try to make new PR when i have a enough time. Thanks for asking!

nessita · 2023-05-23T11:56:37Z

Closing as discussed with the reporter.

jacobtylerwalls reviewed Mar 1, 2021

View reviewed changes

jacobtylerwalls reviewed Mar 2, 2021

View reviewed changes

baidoosik force-pushed the ticket-32398-query branch 3 times, most recently from c9c9566 to 02c4386 Compare March 3, 2021 16:47

jacobtylerwalls reviewed Mar 3, 2021

View reviewed changes

baidoosik force-pushed the ticket-32398-query branch from 02c4386 to 38b0095 Compare March 3, 2021 16:51

jacobtylerwalls reviewed Mar 3, 2021

View reviewed changes

baidoosik force-pushed the ticket-32398-query branch from 38b0095 to 9db889f Compare March 3, 2021 17:59

felixxm reviewed Mar 4, 2021

View reviewed changes

Base automatically changed from master to main March 9, 2021 06:22

baidoosik force-pushed the ticket-32398-query branch 3 times, most recently from 8325706 to bea28ae Compare March 21, 2021 12:48

baidoosik requested a review from felixxm March 24, 2021 04:38

felixxm reviewed May 19, 2021

View reviewed changes

baidoosik force-pushed the ticket-32398-query branch 3 times, most recently from 3730e54 to e53a1da Compare June 1, 2021 13:48

baidoosik force-pushed the ticket-32398-query branch 2 times, most recently from 7d6bdec to ae71755 Compare June 1, 2021 15:17

Fixed#32398--Fixed negated annotation filter on build_filter

37beca0

baidoosik force-pushed the ticket-32398-query branch from ae71755 to 37beca0 Compare June 1, 2021 15:22

jacobtylerwalls mentioned this pull request Apr 10, 2023

Refs #32398 -- Added is_nullable() to BaseExpression. #16748

Closed

nessita closed this May 23, 2023

	def test_null_join_demotion(self):
	qs = ModelA.objects.filter(Q(b__name__isnull=False) & Q(b__name__isnull=True))
	self.assertIn(' INNER JOIN ', str(qs.query))

		if current_negated and lookup_type != 'isnull' and condition.rhs is not None \
		and self.is_nullable(target):

Fixed#32398--Fixed negated annotation filter on build_filter #14065

Fixed#32398--Fixed negated annotation filter on build_filter #14065

Conversation

baidoosik commented Mar 1, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jacobtylerwalls left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

baidoosik Mar 3, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

baidoosik Mar 3, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

felixxm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

baidoosik commented Mar 21, 2021 • edited Loading

baidoosik commented Mar 25, 2021

jacobtylerwalls commented Mar 25, 2021

baidoosik commented Mar 25, 2021

jacobtylerwalls commented Mar 25, 2021

jacobtylerwalls commented Mar 25, 2021

baidoosik commented Mar 25, 2021

baidoosik commented Mar 30, 2021

felixxm commented Mar 30, 2021

baidoosik commented Mar 30, 2021

felixxm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

baidoosik Jul 18, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

baidoosik May 30, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

baidoosik Jun 1, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

baidoosik Jun 1, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

felixxm commented May 19, 2021

nessita commented May 12, 2023

baidoosik commented May 21, 2023

nessita commented May 23, 2023

baidoosik Mar 3, 2021 •

edited

Loading

baidoosik Mar 3, 2021 •

edited

Loading

baidoosik commented Mar 21, 2021 •

edited

Loading

baidoosik Jul 18, 2021 •

edited

Loading

baidoosik May 30, 2021 •

edited

Loading

baidoosik Jun 1, 2021 •

edited

Loading

baidoosik Jun 1, 2021 •

edited

Loading