In general this sounds like a tremendously useful tool... I'm caused to wonder, however... what, if any, are the performance impacts?

--
Curtis



On 08/21/2018 08:10 AM, charettes wrote:
Regarding the lazy loading of deferred fields and foreign keys
I wanted to mention I've been working on a third-party application
that allows overriding the default behavior[0].

The project works by tainting objects retrieved from "sealed"
querysets and having fields descriptors lookup whether or not
the object is "sealed" on attribute access and warn the developer
about it if it's the case. Warnings can be elevated to errors
using `filterwarnings` when deemed appropriated (e.g. CI, staging).

It has been an useful tool to assist in figuring out where
`select_related()` and `prefetch_related()` should be used
to adjust complex projects database interactions.

I assume a similar pattern could be used to mark objects retrieved
from `QuerySet.__aiter__` to prevent non-async queries from being
performed on attribute accesses; on `Model._state.async = True`
field descriptors would error out.


Cheers,
Simon

P.-S.

While the project might look complex most of the code takes care
of the delicate tasks of replacing fields descriptors once models
are configured which could be significantly simplified if it was
part of Django core.

[0] https://github.com/charettes/django-seal
Le samedi 9 juin 2018 02:30:59 UTC-4, Josh Smeaton a écrit :

    I think most of what you've laid out sounds great and that pursuing
    async Django is in the projects best interests. The sync to async
    and async to sync wrappers that have come out of channels give me
    much more confidence that this project is doable in a reasonable
    amount of time with backwards compatibility being preserved.

    The only real concern I have at the moment is around your comments
    regarding on demand foreign key traversal. If existing code running
    synchronously is going to be impacted, that's going to be very
    difficult for a lot of people. If it's only asynchronous traversal
    that'll have issues, then I have no real concern, as on demand
    foreign key fetching is usually a bug anyway.

    Having a brief read through the psycopg asynchronous docs[0], it
    looks like a number of features will be impossible or troublesome to
    use, like transactions, executemany, and named cursors (.iterator()
    with server side cursors). We'd also need to investigate how
    pgbouncer would work in async mode, as most large sites using
    postgres are also using pgbouncer. I would expect support can only
    further improve, especially if there is a driver like django
    pushing. Fallback would just be to run inside a thread pool though,
    so it's not a blocker for the rest of the proposal.

    Very exciting times ahead!

    [0] http://initd.org/psycopg/docs/advanced.html#asynchronous-support
    <http://initd.org/psycopg/docs/advanced.html#asynchronous-support>

    On Monday, 4 June 2018 23:18:23 UTC+10, Andrew Godwin wrote:

        Hello everyone,

        For a while now I have been working on potential plans for
        making Django async-capable, and I finally have a plan I am
        reasonably happy with and which I think we can actually do.

        This proposed roadmap, in its great length, is here:

        https://www.aeracode.org/2018/06/04/django-async-roadmap/
        <https://www.aeracode.org/2018/06/04/django-async-roadmap/>

        I'd like to invite discussion on this potential plan - including:

          - Do we think async is worth going after? Note that this is
        just async HTTP capability, not WebSockets (that would remain in
        Channels)

          - Can we do this in a reasonable timeframe? If not, is there a
        way around that?

          - Are the proposed modifications to how Django runs sensible?

          - How should we fund this?

        There's many more potential questions, and I really would love
        feedback on this. I'm personally pretty convinced that we can
        and should do this, but this is a decision we cannot take
        lightly, and I would love to hear what you have to say.

        Andrew

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com <mailto:django-developers+unsubscr...@googlegroups.com>. To post to this group, send email to django-developers@googlegroups.com <mailto:django-developers@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0b3b92b9-eee7-4909-82d6-c0138e8b5760%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/0b3b92b9-eee7-4909-82d6-c0138e8b5760%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b6c604b0-3040-4f82-8295-ecaafa6192e4%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Reply via email to