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

81–90 of 91 posts

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

#81

Post by LtWorf »

nine_k wrote: post #50
whalesalad wrote: post #41

Earlier quoted context omitted.

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.

dataclasses can do validation too and are faster

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

#82

Post by globular-toast »

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…

One advantage of something like attrs/cattrs is you can use the regular attrs objects inside the module without all the serialisation/validation baggage, then use cattrs to do the serialisation at the edge where you need it.

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

#83

Post by nine_k »

LtWorf wrote: post #81
nine_k wrote: post #50

Earlier quoted context omitted.

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

dataclasses can do validation too and are faster

Dataclasses can skip validation, hence they are faster, when you can trust the inputs.

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

#84

Post by LtWorf »

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...

I mean it would work with attrs and dataclasses as well and you'd also get static type checking and they are faster.

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

#85

Post by gavmor »

ramon156 wrote: post #53
gavmor wrote: post #38

Earlier quoted context omitted.

The two sources of truth are for two disparate adapters. Neither the API nor the DB define the domain, but both must adapt the domain to their respective implementation concerns. The ontology of your persistence layer should be entirely uncoupled from that of your API, which must accommodate an external client. In theory, anyway.

I'd rather define my db domain in-code so I do not have to worry about writing the queries without type hinting. Raw sql -> eh, I don't have the patience Raw sql w type hints -> better, I at least get a compilation error when I do something wrong, and preferably a suggestion ORM -> this usually introduces it's own abstraction that needs it's own maintenance, but at least it's more code-oriented. Yes, SQL is an awesom…

Well yeah, of course. Sorry, when I said "DB" what I should have said was "data-layer," and this can include: repositories, ORM models, query-builders, etc. All of these are type-hinted "db domain in-code" and, still, not one coupled to your API.

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

#87

Post by corv »

Really enjoying this so far!

I’ve replaced about 900 lines of raw SQL and got validation and dashboard for free.

The only gotcha I ran into is that Ty didn’t recognize some of the generated types, but that’s also a young project so I’m willing to turn a blind eye.

Really solid, thank you

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

#88

Post by globular-toast »

mr_Fatalyst wrote: post #79
globular-toast wrote: post #78

Earlier quoted context omitted.

Cool, that does sound like what I was after. To expand a bit on this, what I'm thinking about is a modular monolith architecture. It's also a pragmatic approach where you don't need to split into separate (micro)services yet, but you still want things to be modular and able to split later if need be. While things are still in the same monolith there's no point actually doing the serialise/deserialise step to enable i…

The way I see it, having everything as Pydantic makes this natural. Your DB model, your request schema, your response DTO are all BaseModels. Converting between them is just model_dump() and model_validate(), or plain inheritance. No adapters, no mapping layers. So when you need to split things apart, it's straightforward rather than painful.

Yeah, but I'm afraid of a system like Django where not calling `.save()` in the wrong place is down to discipline and understanding. I want there to be some way to stop this happening that doesn't rely on a couple of maintainers keeping strict vigilance over the codebase.

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

#90

Post by gcr »

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…

Agreed. They really should be separate.

Suppose an API GET /users/:username call returns a "User" type. If returns the the same type as in your database, wouldn't you also get their password hash as well with that request? How do coupled frameworks deal with this?

Post reply on HN