Toasty, an async ORM for Rust

Posted by steveklabnik 10/23/2024

214 points | 141 commentspage 2

ericyd 10/26/2024|

I find the syntax confusing. Setting properties and even creating associated model instances is done with opaque method names like `.name()` and `.todo()`. I'm not always a fan of using set/get prefixes, but I think there should be some differentiation for an ORM which is inherently involved in property access. I'm particular it is strange and surprising to me that `.todo()` would associate another model. Why not "add_todo" or "create_todo"? What if the association is not one to many but one to one? The method `.todos()` retrieves a list of Todos, but what if we're talking about a 1:1 Profile model? How would a user differentiate between setting and getting a `.profile()`?

I'm not a rust person so I might just be exposing my ignorance here, just wanted to provide feedback since it's on early development.

cutler 10/27/2024||

Why, oh why? Just SAY NO TO ORMs, especially in non-OO languages.

tricked 10/24/2024||

Looks well thought out i like that for the most part this seems faster/easier than rolling your own sql query mapping etc compared to the other solutions I've come across in rust

isodev 10/26/2024||

Nice, I love it!

It reminds me of Prisma and yet, it's all Rust. Also good to see that async is the focus point of the API so the usage feels ergonomic.

cyndunlop 10/24/2024||

Toasty was the focus of Carl Lerche's P99 CONF keynote on Wednesday. It provoked some interesting discussion in the chat.

arandomusername 10/23/2024||

Looks awesome. Would love to see the table definitions that are generated from the schema as well.

fulafel 10/26/2024||

Why is asynchronity (sp?) a concern of the ORM in this case?

BiteCode_dev 10/26/2024|

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.

fulafel 10/26/2024|||

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?

baq 10/26/2024||||

this has been a solved problem for... a long time, can't remember how long even.

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 10/26/2024||

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

The situation might change some day though, once async support in the core language and surrounding ecosystem gets stronger.

satvikpendem 10/26/2024||

diesel_async exists and is also maintained by the same creator.

GolDDranks 10/28/2024||

Yes, but it started as a experiment, and isn't official part of Diesel yet.

satvikpendem 10/28/2024||

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.

spintin 10/26/2024|||

[dead]

revskill 10/24/2024||

O in orm is misleading term. To me orm is about table.

OJFord 10/26/2024|

O refers to the OOP object, it's the R that's the (relational) database.

randomdata 10/26/2024|||

I expect the parent meant to write R instead of O. It is misleading as nobody ever maps relational databases. As the parent points out, usually they reach for tablational databases. This project also supports a key/value database. But it does not even support relational databases.

Further, the project is focused on implementing the active record pattern, so it would be more appropriately called an async active record than an "async ORM".

0x457 10/26/2024||

but active record is just one of patterns that can be used to implement an ORM?

randomdata 10/27/2024||

Active record traditionally depends on ORM, but cannot implement it. ORM exists at a lower layer of abstraction.

dvdbloc 10/26/2024||

Is it just me or why does Rust have all these confusing names that seemingly have nothing to do with the functionality of the module/crate? Or maybe I’m just used to the names in Python and C++ packages for performing common tasks. It just seems to make it harder for a newcomer to locate what packages they should be using when they want to perform some common function.

LtdJorge 10/26/2024|

Yep, for example hearing Jinja tells you right away what the package does.

jruz 10/26/2024|

Meh, the article makes it sound as if there were nothing and we have already solid options like SeaORM and Diesel.

Still to me they all suck and nothing beats SQLx

More comments...