The openapi.definition decorator struggles in a sync context about sanic-ext HOT 8 CLOSED

Thanks, definitely not intended and needs investigation and a fix.

from sanic-ext.

So, I am not sure that this actually a bug here. This seems to work on both def and async def.

from sanic import Request, Sanic, json
from sanic_ext import openapi
from sanic_ext.extensions.openapi import definitions as oa

app = Sanic(__name__)


class Error:
    ...


class TopTracksResponse:
    ...


@app.get("/")
@openapi.definition(
    summary="Fetch top tracks",
    response=[
        oa.Response(TopTracksResponse),
        oa.Response(
            Error, status=404, description="not found. note: sync is required."
        ),
        oa.Response(Error, status=400, description="bad request"),
    ],
)
def handler(request: Request):
    return json({"foo": "bar"})

Looking at your exception, the problem looks to be something instead that Django has introduced. Namely, if there is a running event loop, then bail out:

It looks like they provide you with an escape hatch though:

from os import environ

environ["DJANGO_ALLOW_ASYNC_UNSAFE"] = True

from sanic-ext.

I'll be honest, this is the first time that I have heard of someone using Django ORM inside Sanic. I am curious to know more about how you wired that up and your experience of and motivation for doing so.

from sanic-ext.

Yeah, totally, the error itself triggers when Django ORM is run, but the idea is that I was able to use the Django ORM inside my views without any problems because the view wasn't triggered as a coroutine until I add the documentation decorator. So it was fully compatible with the Django ORM in many cases, but the decorator converted the view as a coroutine, so I had to add some patch for Django ORM. Anyway, totally agree that this is not a bug itself, meaning that it's just incompatibility (without a workaround) with some non-async projects.

from sanic-ext.

I'll be honest, this is the first time that I have heard of someone using Django ORM inside Sanic. I am curious to know more about how you wired that up and your experience of and motivation for doing so.

The motivation of why we choose Django resides in various ideas; The most important is that Django 4.1 releases in a couple of months with a new Asynchronous ORM interface so it will be fully compatible with Sanic in every case. So at my opninion we're at doors to have projects with Sanic as REST Framework and Django as ORM, since -as my point of view- Sanic is way better as a REST framework, in many cases. Ours included.
Until now, we were working with Peewee but for many issues with it, we decide that we're going to play safe and use Django since we had more experience with it and it's widely recognized. We love Sanic for its Flask-type design, and obviously, the amazing performance it has, so we are excited about this new Django upgrade and loving the idea of working with Sanic and Django comfortably.

For now, until this update comes, we're basically mantaining the Django ORM inside Sanic encapsulating some views and services inside the asgiref.sync.sync_to_async method - as it's well explained in the Django documentation. And as support, we have a little async Django manager to work with QuerySets asynchronously, but we use it just for little things, and our motivation to have it is to have our views async as much as we can. It is not an ideal scenario, but works for us and as I said is just a migration step before upgrading to Django 4.1. We understand that our current setup (basically using Django ORM) will have some penalizations on the application general performance, but we're fine with it since we're gonna fix it soon with this new upgrade.

from sanic-ext.

It looks like they provide you with an escape hatch though:

from os import environ

environ["DJANGO_ALLOW_ASYNC_UNSAFE"] = True

And for this approach, this is highly unsafe and not recommended on production environments since it leads to data loss, but it could work for us in a test environment, yes!

from sanic-ext.

Thanks for the information. I did not know about the ORM coming with an async version soon. Progress!

this is highly unsafe and not recommended on production environments since it leads to data loss

How so? All they are doing is checking if there is a loop. I am not sure that I see how this would lead to data loss.

from sanic-ext.

Closing this as it is a Django issue.

from sanic-ext.