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

41–50 of 91 posts

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

#41

Post by whalesalad »

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…

A lot of people have this misconception that Pydantic models are only useful for returning API responses. This is proliferated by all-in-one frameworks like FastAPI.

They are useful in and of themselves as internal business/domain objects, though. For a lot of cases I prefer lighter weight dataclasses that have less ceremony and runtime slowdown with the validation layer, but we use Pydantic models all over the place to guarantee and establish contracts for objects flowing thru our system, irrespective of external facing API layer.

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

#42

Post by whalesalad »

luckycharms810 wrote: post #30

As a non ORM person - I do love the Pydantic functionality that comes out of the box w pyscopg3. https://www.psycopg.org/psycopg3/docs/advanced/typing.html#e...

wow big if true. our core codebase is still on psycopg2 and we do this mapping ourselves. type introspective would be very handy for reducing that boilerplate.

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

#43

Post by abybaddi009 »

TZubiri wrote: post #29
mr_Fatalyst wrote: post #14

Earlier quoted context omitted.

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.

Here's OpenEdx extensively using ORM: https://github.com/openedx/openedx-platform

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

#45

Post by ryan14975 »

The coupling concern is valid but I think it's the right trade-off for most CRUD apps. In practice, 80% of your endpoints are thin wrappers around your models anyway. The remaining 20% where you need separate request/response schemas — you just write those by hand.

The auto-generated admin panel is a nice touch. That alone saves days on internal tooling.

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

#47

Post by nine_k »

giovannibonetti wrote: post #26
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/

Nice! But what about type checking?

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

#48

Post by nine_k »

bb88 wrote: post #40
ElectricalUnion wrote: post #37

Earlier quoted context omitted.

I also find it really strange this weird ORM fascination. Besides the generic "ORM are the Vietnam War of CS" feeling, I feel that with average database to ORM/REST things, end up with at least one of: a) you somehow actually have a "system of record", so modelling something in a very CRUD way makes sense, but, on the other hand, who the hell ends up building so many system of record systems in the first place to nee…

The vietnam of computer science was written 20 years ago (2006 even), and didn't kill off ORMs then. We've only had 20 years of improvement of ORMs since then. We've long ago accepted Vietnam (the country) as what it is and what it will be in the forseeable future. We should do the same with ORM. I for one don't want to write in a low level assembly language, and shouldn't have to in 2026. Yet, SQL still feels like o…

SQL is a pretty high-level, declarative language. It's unnecessarily wordy though, and not very composable.

The problem with ORMs is that they usually give you a wrong abstraction. They map poorly on how a relational database works, and what it is capable of. But the cost of it is usually poor performance, rarely it's obvious bugs. So it's really easy to get started to use; when it starts costing you, you can optimize the few most critical paths, and just pay more and more for the DB. This looks like an okay deal for the industry, it seems.

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

#50

Post by nine_k »

whalesalad wrote: post #41
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…

A lot of people have this misconception that Pydantic models are only useful for returning API responses. This is proliferated by all-in-one frameworks like FastAPI. They are useful in and of themselves as internal business/domain objects, though. For a lot of cases I prefer lighter weight dataclasses that have less ceremony and runtime slowdown with the validation layer, but we use Pydantic models all over the place…

Pydantic models are validating. Hence their natural place is interfaces with external systems, outside the reach of your typechecker.
Post reply on HN