-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
chore(deps): Upgrade to Django 4.2 #18653
Conversation
We need to be on >= 3.1.8 Locally there is an additional problem that somehow psycopg2 seemingly overshadows psycopg, making it appear that 3.1 works. Had to install pip install "psycopg[binary,pool]==3.1.2" to recreate the problem.
We use custom SQL that somehow doesn't get formatted in the right way using server or client side cursors.
Size Change: -2.05 kB (0%) Total Size: 2.01 MB
|
Because full_clean validates since Django 4.1, see https://docs.djangoproject.com/en/4.2/releases/4.1/#validation-of-constraints
Come up as error: Unused "type: ignore" comment
@pauldambra We are green on Django 4.1 🚀 |
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.
very quick scan, all looks good apart from the sql commenting.
I'll check it out and run it later on
@@ -48,7 +48,7 @@ | |||
"posthog_organization"."available_features" | |||
FROM "posthog_organization" | |||
WHERE "posthog_organization"."id" = '00000000-0000-0000-0000-000000000000'::uuid | |||
LIMIT 21 /*controller='organization_resource_access-list',route='api/organizations/%28%3FP%3Cparent_lookup_organization_id%3E%5B%5E/.%5D%2B%29/resource_access/%3F%24'*/ |
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 don't remember where they're set but it looks like the useful SQL commenting has stopped working
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.
reasonably sure it's the sql commenter: https://github.com/PostHog/posthog/blob/master/posthog/settings/web.py#L90
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.
It seems Google gave this sqlcommenter to opentelemetry and it was not updated in a long time.
This might be where it ended up:
https://opentelemetry-python-contrib.readthedocs.io/en/latest/instrumentation/django/django.html#sqlcommenter
However, then there's this about supporting psycopg3, which I think might be the problem we have:
open-telemetry/opentelemetry-python-contrib#1751
How much do we need it anyways?
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.
oh dang it!
It's pretty useful for knowing where the request is coming from, specially when looking in, say, pganalyze for most popular sources of sql requests.
But, we do this manually for clickhouse ourselves, so wonder if there's an easy / small-scoped way to just do it ourselves
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've investigated further and also tried to use the middleware from opentelemetry that has some modifications as it seems.
Unfortunately, then immediately the following issue comes up 🥴
open-telemetry/opentelemetry-python-contrib#1554
It seems there are some differences between how the queries are handled and how the wrappers are executed. This would also explain why the pg_sleep
wrapper has no effect anymore.
I'd say for now I'll make another PR just to upgrade to Django 4.1, where I had all CI green. Or does anyone have any suggestions?
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.
Yep... a step on the road that works 🚀
I've created #18830 for Django 4.1 and would propose to leave this one here open to track issues for 4.2 |
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the |
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the |
Because not maintained anymore
This reverts commit c2a7ef8.
I merged master into this PR to update it and fixed some more issues, others meanwhile went away. One issue is that mypy shows errors in CI that I don't see locally. @pauldambra or @neilkakkar can someone check this locally as well and possibly just update the baseline? |
@@ -3962,7 +3962,7 @@ def test_feature_flags_v3_consistent_flags(self, mock_is_connected): | |||
# make sure caches are populated | |||
response = self._post_decide() | |||
|
|||
with self.assertNumQueries(5, using="replica"), self.assertNumQueries(0, using="default"): | |||
with self.assertNumQueries(9, using="replica"), self.assertNumQueries(0, using="default"): |
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.
weird, how are there so many extra queries for flags, would you mind sharing the output here? I can look into this soon-ish as well
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.
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.
Yeah the increases should only be from this, the count changes do match that.
@@ -790,7 +790,8 @@ def get_all_feature_flags( | |||
distinct_ids = [distinct_id, str(hash_key_override)] | |||
query = """ | |||
WITH target_person_ids AS ( | |||
SELECT team_id, person_id FROM posthog_persondistinctid WHERE team_id = %(team_id)s AND distinct_id IN %(distinct_ids)s | |||
SELECT team_id, person_id FROM posthog_persondistinctid WHERE team_id = %(team_id)s AND | |||
distinct_id = ANY(%(distinct_ids)s) |
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.
this is in preparation for psycopg3 update?
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.
This is the psycopg3 update as with Django 4.2 it's used actively.
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.
hmm, oh I see, I was looking at docs for psycopg3.2.0, https://www.psycopg.org/psycopg3/docs/basic/from_pg2.html#server-side-binding - this is what I expect will cause the pg_sleep() tests to fail because it sends a SET command with parameter binding
but we can leave this be for when its actually released :P
Also had a look at the psycopg2 usage still in the app, we can remove it in a follow up indeed, no need to do it right now. 👍
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.
Great job!
When we roll-out we should pause deploys and test this in dev / test in a canary deploy first!
Problem
Upgrade to latest Django version.
Changes
Issues left:
this issue vanished 🤷🏻pg_sleep(1)
to make tests simulate slow DB is somehow not appliednewthis as wellduplicate key value violates unique constraint "posthog_organization_slug_key"
errors come upHow did you test this code?