Re:Show HN: Oxyde – Pydantic-native async ORM with a Rust core
by Onavo on Monday March 16, 2026 @08:42PM
(#47407136)
With this you don't need to have two sources of truth on the backend. Previously you will end up with one set of DB ORM level validation and a second set of validation on the data transfer object and you have to make sure the types line up. Now the data transfer object will automatically inherit the correct types.
[ Parent
| on HN ]
Re:Show HN: Oxyde – Pydantic-native async ORM with a Rust core
by gavmor on Monday March 16, 2026 @09:29PM
(#47407482)
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.
Re:Show HN: Oxyde – Pydantic-native async ORM with a Rust core
by ramon156 on Tuesday March 17, 2026 @03:12AM
(#47409551)
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 awesome solution to querying DB's, hence I prefer option 2
Re:Show HN: Oxyde – Pydantic-native async ORM with a Rust core
by gavmor on Tuesday March 17, 2026 @04:32PM
(#47417904)
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
by mr_Fatalyst on Monday March 16, 2026 @09:06PM
(#47407318)
Exactly, that's the idea.