Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Oxyde – Pydantic-native async ORM with a Rust core

github.com

Post reply on HN
Print view View original

21–30 of 91 posts

Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core

#21

Post by mr_Fatalyst »

instig007 wrote: post #20
mr_Fatalyst wrote: post #12

Earlier quoted context omitted.

The Rust core is not just about speed. It bundles native database drivers (sqlx), connection pooling, streaming serialization. It's more about the full IO stack than just making Python faster. On F("views"), fair point. It's a conscious trade-off for now. The .pyi stubs cover filter(), create(), and other query methods, but F() is still stringly-typed. Room for improvement there.

> It's more about the full IO stack than just making Python faster. Does it mean that your db adapter isn't necessarily DBAPI (PEP-249) compliant? That is, it could be that DBAPI exception hierarchy isn't respected, so that middlewares that expect to work across the stack and catch all DB-related issues, may not work if the underlying DB access stack is using your drivers? > but F() is still stringly-typed. Room for…

Right, it's not DBAPI compliant. The whole IO stack goes through Rust/sqlx, so PEP-249 doesn't apply. Oxyde has its own exception hierarchy (OxydeError, IntegrityError, NotFoundError, etc.). In practice most people catch ORM-level exceptions rather than DBAPI ones, but fair to call out.

On F(), good point. The descriptor approach is something I've been thinking about. Definitely on the radar.

Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core

#22

Post by whinvik »

roel_v wrote: post #8

Why would one want to couple these two? Doesn't that couple, say, your API interface with your database schema? Whereas in reality these are separate concepts, even if, yes, sometimes you return a 'user' from an API that looks the same as the 'user' in the database? Honest question, I only just recently got into FastAPI and I was a bit confused at first that yes, it seemed like a lot of duplication, but after a littl…

Yeah I have always struggled to figure out why I would use SQLModel.

Big fan of FastAPI but I think SQLModel leads to the wrong mental model that somehow db model and api schema are the same.

Therefore I insist on using SQLAlchemy for db models and pydantic for api schemas as a mental boundary.

Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core

#26

Post by giovannibonetti »

roel_v wrote: post #8

Why would one want to couple these two? Doesn't that couple, say, your API interface with your database schema? Whereas in reality these are separate concepts, even if, yes, sometimes you return a 'user' from an API that looks the same as the 'user' in the database? Honest question, I only just recently got into FastAPI and I was a bit confused at first that yes, it seemed like a lot of duplication, but after a littl…

You might be interested in a library that flips around the concept of an ORM, like sqlc [1] or aiosql [2]. You specify just what you want from the database, without needing to couple so much API with database tables.

[1] https://sqlc.dev/ [2] https://nackjicholson.github.io/aiosql/

Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core

#27

Post by miki123211 »

roel_v wrote: post #8

Why would one want to couple these two? Doesn't that couple, say, your API interface with your database schema? Whereas in reality these are separate concepts, even if, yes, sometimes you return a 'user' from an API that looks the same as the 'user' in the database? Honest question, I only just recently got into FastAPI and I was a bit confused at first that yes, it seemed like a lot of duplication, but after a littl…

I think they should be related but not the same.

With proper DRY, you shouldn't need to repeat the types, docstrings and validation rules. You should be able to say "these fields from user go on its default presenter, there are two other presenters with extra fields" without having to repeat all that info. I have a vague memory that Django Rest Framework does something of the sort.

This feels hard to express in modern type systems though. Perhaps the craziness that is Zod and Typescript could do it, but probably not Python.

Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core

#29

Post by TZubiri »

mr_Fatalyst wrote: post #14
TZubiri wrote: post #11

Didn't the committee agree that ORMs were a mistale and a thing of the past?

Must have missed that meeting. ORMs are not for everything, but for CRUD-heavy apps with validation they save a lot of boilerplate. And there's always execute_raw() for when you need to go off-script.

If there's an Open Source application that you can show me as a good example of ORM usage, I'd be interested in seeing it as a steelman argument for them.
Post reply on HN