About 3000 LoC changed later and now user data is stored in a database instead of just as JSON in folders #SeaORM

Kudos to the developers of #SeaORM! It's so flexible, feature-rich, efficient and easy to use, I've never had such a great experience with an ORM in any language before. Flexibility is a real game changer. It's mind-blowing how it lets me customize my queries to the finest details while still not having to write raw SQL.

Definitely elevates my #Rust experience.

Here I see that SeaORM is just some added burden. I see no benefit in using it for my project.

You need to learn their API (DSL) to query the database.

It names its stuff "entities" and "models" and you have to come up with another name for your business models.

Extremely difficult to work with relation ships. Even harder if you models have multiple or chained relation ships.

#seaorm

After testing both SeaORM & Tokio Postgres:

With both, you still need to manually write
- junction table
- migrations
- mappings to your useful or complex types/structs.

So basicaly you just get almost raw result from a database that is a SQL table representation that you transform to you business models.

#seaorm #postgres #tokioPostgres

But this time, after struggling to find a complete and practical example online, I decided to go for it and build my own.

This is a #REST #API written in #Rust 🦀, using #ActixWeb ⚙️ and #SeaORM 🐚 as the ORM, with #PostgreSQL 🐘 as the database. The repository has two branches:

Now that I've got the #SeaORM's DatabaseConnection picked up in #rust #warp's filter, I can proudly say that I've got a basic understanding of FnOnce vs FnMut vs Fn.
Finally, I got the std::sync::Mutex vs futures::lock::Mutex, this was the last hurdle to make it work.

#Poem and #SeaORM (sea-orm) is the #Python #FastAPI + #SqlModel equivalent in #Rust. Seems pretty easy to use.

This turned out into an interesting journey, I learned a lot about #seaorm by reading what #loco did with it, how they enhanced it. My current #rust implementation remains purely #seaorm based, but #loco has a lot to offer. Using just the #seaorm layer #loco built seems attractive.

I am really disapointed I have to define a lot of join tables and write tons of inserts. I am using SeaORM but the issue is also present in Diesel as I can tell.

#rust #seaORM

So I looked at Diesel and it has the same problem with writing migrations. One needs to manually write join tables and stuff.

#rust #diesel #seaORM

Why do we have to write migrations first with SeaORM?

It makes me think and waste energy on trivial repetitive tasks like what to name my join table and write its up and down statements.

#rust #SeaORM

Is there a recent, balanced article/blog post/video/whatever discussing the pros and cons of the different #SQL crates for #rustlang #rust ? Getting more and more frustrated with #sqlx , considering switching to #diesel or #seaorm but maybe (probably) it's just me using it wrong...

@kicolobo o texto também está um pouco defasado (em 1 ano). Para a área dele, agora existem ferramentas bem maduras como #axum, #tokio, #seaorm e #sqlx.
O problema foi ir no bafo da novidade sem ter mão de obra especializada, coisa que #golang não nessecita (e que como comentamos), que é uma das grandes vantagens da linguagem. Típico tiro no escuro.

After almost two days, I finally port my #rustlang RSS Api from #SeaORM to #sqlx

I really liked SeaORM, but I need something closer to the database so I can tinker with my queries.

I still need to rewrite the tests but... not today!

I'm currently using #SeaORM for the RSS Api I'm working on. It's great and all, but sometime it can be a bit frustrating, because of the whole boiler plate that can happen sometime.

So I try to convert everything to #sqlx and I get frustrated by other things.

Life is hard.

#rust #rustlang

I’ve been doing some tests . My goal is to rewrite a #djangorestframework API in #rust.

There are so many web and async frameworks, it’s hard to choose!

So far my best attempt was #tide with #SeaORM

Very happy.
Made good progress. web form #CRUD now complete for first db table Song_Books working in #PrayerOfHannah
#RustLang #Axum #SeaOrm
All code on @Codeberg (which I see has been updated to use @forgejo ) at
https://codeberg.org/Dave42W/PrayerOfHannah
#CodeBerg #Forgejo

Ok toasted sandwiches made and all in the freezer.
Now a bit of playing with #PrayerOfHannah using #RustLang
Got all #SeaOrm #Axum etc installed and going to define the first tables in the migration script (table definitions are going to be incredibly unstable for quite a while).
Enjoying a nice coffee too 😃

It has taken me ages but I finally have #SeaOrm migration creating and dropping an index. In the process, I think I have gained a better grasp of working with #RustLang Result
Should be useful when I revisit getting SeaOrm to work cleanly with #Axum StatusCode
All committed in #CodeBerg at https://codeberg.org/Dave42W/daves_dashboard

Ok, in today's #RustLang I have managed to wrap #SeaOrm Update and Delete in transactions. In #Axum I've got Insert, Update and Delete redirecting url's properly.
There are a few cases where I would like to return nice HTTP status codes (such as if another user has deleted the row before your transaction starts).
Struggling to get those different responses to work as I want.