Skip to content
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

Now storing active schema in asgiref.local #120

Merged
merged 5 commits into from
Oct 18, 2022
Merged

Now storing active schema in asgiref.local #120

merged 5 commits into from
Oct 18, 2022

Conversation

lorinkoz
Copy link
Owner

No description provided.

@lorinkoz lorinkoz changed the title Major code revamp Now storing active schema in asgiref.local Aug 27, 2022
@lorinkoz lorinkoz marked this pull request as ready for review August 27, 2022 22:22
@lorinkoz lorinkoz requested a review from ktowen August 27, 2022 22:22
ey3ball pushed a commit to ey3ball/django-tenants that referenced this pull request Aug 29, 2022
This fixes django-tenants#820 until a better method is
found.

The root cause is that information stored on connections is not
available on all contexts during the processing of a request. In WSGI
mode a single thread is involved so this is not visible. In ASGI mode
however some code execute in the context of the async event loop. This
is because the connection handler stores information in a
thread_critical variable as seen here https://github.com/django/django/blob/main/django/utils/connection.py#L41.

A better method would be to use asgi.local with our own sharing policy
instead instead of attaching to the connexion object.

Until that is settled (@lorinkoz has a prototype in
lorinkoz/django-pgschemas#120) this patch
modifies urlconf management in the subpath middleware.

IO/connection operations which were previously done during resolve() are
removed, which prevents the error from popping up in ASGI mode

The downside is that we're modifying that we're generating a new urlconf
object for each tenant. Also, this fixes a particular subpath issue, but
does not address the more general issue of using connection to store a
state accross each request processing.
ey3ball pushed a commit to ey3ball/django-tenants that referenced this pull request Aug 29, 2022
This fixes django-tenants#820 until a better method is
found.

The root cause is that information stored on connections is not
available on all contexts during the processing of a request. In WSGI
mode a single thread is involved so this is not visible. In ASGI mode
however some code execute in the context of the async event loop. This
is because the connection handler stores information in a
thread_critical variable as seen here https://github.com/django/django/blob/main/django/utils/connection.py#L41.

A better method would be to use asgi.local with our own sharing policy
instead instead of attaching to the connexion object.

Until that is settled (@lorinkoz has a prototype in
lorinkoz/django-pgschemas#120) this patch
modifies urlconf management in the subpath middleware.

IO/connection operations which were previously done during resolve() are
removed, which prevents the error from popping up in ASGI mode

The downside is that we're modifying that we're generating a new urlconf
object for each tenant. Also, this fixes a particular subpath issue, but
does not address the more general issue of using connection to store a
state accross each request processing.
@lorinkoz lorinkoz merged commit 1ba66d0 into master Oct 18, 2022
@lorinkoz lorinkoz deleted the revamp branch October 18, 2022 19:48
fvallee-fbx added a commit to fvallee-fbx/django-tenants that referenced this pull request Jun 5, 2023
This fixes django-tenants#820 until a better method is
found.

The root cause is that information stored on connections is not
available on all contexts during the processing of a request. In WSGI
mode a single thread is involved so this is not visible. In ASGI mode
however some code execute in the context of the async event loop. This
is because the connection handler stores information in a
thread_critical variable as seen here https://github.com/django/django/blob/main/django/utils/connection.py#L41.

A better method would be to use asgi.local with our own sharing policy
instead instead of attaching to the connexion object.

Until that is settled (@lorinkoz has a prototype in
lorinkoz/django-pgschemas#120) this patch
modifies urlconf management in the subpath middleware.

IO/connection operations which were previously done during resolve() are
removed, which prevents the error from popping up in ASGI mode

The downside is that we're modifying that we're generating a new urlconf
object for each tenant. Also, this fixes a particular subpath issue, but
does not address the more general issue of using connection to store a
state accross each request processing.
McDonnellJoseph pushed a commit to McDonnellJoseph/django-tenants that referenced this pull request Jul 15, 2024
This fixes django-tenants#820 until a better method is
found.

The root cause is that information stored on connections is not
available on all contexts during the processing of a request. In WSGI
mode a single thread is involved so this is not visible. In ASGI mode
however some code execute in the context of the async event loop. This
is because the connection handler stores information in a
thread_critical variable as seen here https://github.com/django/django/blob/main/django/utils/connection.py#L41.

A better method would be to use asgi.local with our own sharing policy
instead instead of attaching to the connexion object.

Until that is settled (@lorinkoz has a prototype in
lorinkoz/django-pgschemas#120) this patch
modifies urlconf management in the subpath middleware.

IO/connection operations which were previously done during resolve() are
removed, which prevents the error from popping up in ASGI mode

The downside is that we're modifying that we're generating a new urlconf
object for each tenant. Also, this fixes a particular subpath issue, but
does not address the more general issue of using connection to store a
state accross each request processing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants