5 ms·

Because ORM attribute access usually trigger requests, and you must design the API so that those requests, which trigger called to the network, don't block.

baq 2y ago
this has been a solved problem for... a long time, can't remember how long even. https://docs.sqlalchemy.org/en/20/orm/queryguide/relationships.html#preventing-unwanted-lazy-loads-using-raiseload https://docs.sqlalchemy.org/en/20/orm/queryguide/relationshi... the older I get the more I'm convinced this should be the default behavior.
- GolDDranks 2y ago
  I think you are talking past each others. Preventing N+1 by doing lazy fetching and having synchronous / asynchronous API are orthogonal issues. Async API must not block the thread/event loop when the data loading is being done. Diesel hasn't been providing an async API for reason told in this thread: https://github.com/diesel-rs/diesel/issues/399 https://github.com/diesel-rs/diesel/issues/399 The situation might change some day though, once async support in the core language and surrounding ecosystem gets stronger.
  - satvikpendem 2y ago
    diesel_async exists and is also maintained by the same creator.
    - GolDDranks 2y ago
      Yes, but it started as a experiment, and isn't official part of Diesel yet.
      - satvikpendem 2y ago
        The creator said it is production ready, and that it will never be "officially" part of diesel as diesel only supports a sync interface. Nevertheless, diesel_async is fully fine to use, he mentions.
fulafel 2y ago
I see, the ORM backed objects are lazy and trigger I/O when the data is accessed. On first blush I'm surprised that Rust culture would go for this as it spread network i/o (incl network errors), async waiting and memory allocation widely in your code. This would seemto hamper eg the common "functional core, imperative shell" architecture which gets you many of the classic FP virtues. I wonder if I'm missing something that makes these less of a problem?
spintin 2y ago
[dead]

baq 2y ago

this has been a solved problem for... a long time, can't remember how long even. https://docs.sqlalchemy.org/en/20/orm/queryguide/relationships.html#preventing-unwanted-lazy-loads-using-raiseload https://docs.sqlalchemy.org/en/20/orm/queryguide/relationshi... the older I get the more I'm convinced this should be the default behavior.

GolDDranks 2y ago
I think you are talking past each others. Preventing N+1 by doing lazy fetching and having synchronous / asynchronous API are orthogonal issues. Async API must not block the thread/event loop when the data loading is being done. Diesel hasn't been providing an async API for reason told in this thread: https://github.com/diesel-rs/diesel/issues/399 https://github.com/diesel-rs/diesel/issues/399 The situation might change some day though, once async support in the core language and surrounding ecosystem gets stronger.
- satvikpendem 2y ago
  diesel_async exists and is also maintained by the same creator.
  - GolDDranks 2y ago
    Yes, but it started as a experiment, and isn't official part of Diesel yet.
    - satvikpendem 2y ago
      The creator said it is production ready, and that it will never be "officially" part of diesel as diesel only supports a sync interface. Nevertheless, diesel_async is fully fine to use, he mentions.

fulafel 2y ago

I see, the ORM backed objects are lazy and trigger I/O when the data is accessed. On first blush I'm surprised that Rust culture would go for this as it spread network i/o (incl network errors), async waiting and memory allocation widely in your code. This would seemto hamper eg the common "functional core, imperative shell" architecture which gets you many of the classic FP virtues. I wonder if I'm missing something that makes these less of a problem?

spintin 2y ago

[dead]