mr_Fatalyst

7 ms·

1.
by mr_Fatalyst 6mo ago
Thanks, appreciate the support (^_^)!
2.
by mr_Fatalyst 6mo ago
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 adapte
3.
by mr_Fatalyst 6mo ago
One thing that might help here: if you subclass an Oxyde model without defining class Meta: is_table = True, the child class won't be a table and won't have ORM behavior. So you can inherit the fields and validation but without sa
4.
by mr_Fatalyst 6mo ago
Right now makemigrations detects add/drop/alter columns, indexes, foreign keys, and constraints. Rename is treated as drop + create, same as Django's default. Automatic rename detection is on the roadmap but not there yet. Fo
5.
by mr_Fatalyst 6mo ago
That's exactly why Oxyde has no lazy loading at all. If you don't call .join() or .prefetch(), related data simply won't be there. N+1 is impossible by design, not by discipline.
6.
by mr_Fatalyst 6mo ago
Yep, there's a full comparison including SQLAlchemy async: https://oxyde.fatalyst.dev/latest/advanced/benchmarks/
7.
by mr_Fatalyst 6mo ago
Thanks! Not yet, it's still v0.5 and the API hasn't fully stabilized. But it's getting there.
8.
by mr_Fatalyst 6mo ago
1. We're all AI agents in a simulation anyway... 2. A converter still means maintaining two model systems. The point was to not have two in the first place. 3. MessagePack overhead is negligible compared to actual DB round-trips. And t
9.
by mr_Fatalyst 6mo ago
Well said, that's pretty much how I see it too. Thanks!
10.
by mr_Fatalyst 6mo ago
Right now it's CLI-based: 'oxyde migrate'. You can call 'apply_migrations()' programmatically, but that's not a publicly documented API yet. Good point though, worth adding.
11.
by mr_Fatalyst 6mo ago
Thanks! The admin panel supports Quart out of the box, so you should be good to go.
12.
by mr_Fatalyst 6mo ago
Good question. Working with Python objects in PyO3 requires holding the GIL. With MessagePack, Python serializes to bytes, hands them off, and Rust works completely GIL-free from that point. Same on the way back. So the GIL is held only for
13.
by mr_Fatalyst 6mo ago
You can't call filter() without a model. It's always Folder.objects.filter(user_id=user_id), so the context is right there in the code. Plus the generated .pyi stubs give your IDE full type info per model, so "go to usages&qu
14.
by mr_Fatalyst 6mo ago
Exactly, that's the idea.
15.
by mr_Fatalyst 6mo ago
For Oxyde specifically, it's still a young project, so the best public examples I have are the FastAPI tutorial ( https://github.com/mr-fatalyst/fastapi-oxyde-example ) and the admin panel examples ( https:/&#x
16.
by mr_Fatalyst 6mo ago
Thanks! Haven't used Prisma much myself, but glad the approach resonates.
17.
by mr_Fatalyst 6mo ago
Thanks, appreciate it! Felt wrong to ship an ORM without one.
18.
by mr_Fatalyst 6mo ago
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-
19.
by mr_Fatalyst 6mo ago
Yeah, we're running out of ways to spell oxide (^_^)
20.
by mr_Fatalyst 6mo ago
Thanks! Not really trying to replace Django ORM though, it's great at what it does. Just trying to build the ORM I'd personally want to use in 2026.
21.
by mr_Fatalyst 6mo ago
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.
22.
by mr_Fatalyst 6mo ago
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&#x
23.
by mr_Fatalyst 6mo ago
The ORM doesn't force you to use the DB model as your API schema. It's a regular Pydantic BaseModel, so you can make separate request/response schemas whenever you need to. For simple CRUD, using the model directly saves boil
24.
by mr_Fatalyst 6mo ago
I was surprised too when I saw the results. The benchmarks test standard ORM usage patterns, not the full power of any ORM. SQLAlchemy is more flexible, but that flexibility comes with some overhead. That said, the ORM layer is rarely the b
25.
by mr_Fatalyst 6mo ago
Thanks! Yeah, that SQLModel issue is actually one of the things that pushed me to build this. In Oxyde the models are just Pydantic BaseModel subclasses, so validation always works, both on the way in and on the way out via model_validate()
26.
by mr_Fatalyst 6mo ago
Just pip install oxyde, that's it. The Rust core (oxyde-core) ships as pre-built wheels for Linux, macOS, and Windows, so no Rust toolchain needed. Python-side dependencies are just pydantic, msgpack, and typer for the CLI. Database dr
27.
Show HN: Oxyde – Pydantic-native async ORM with a Rust core(github.com)
155 points by mr_Fatalyst 6mo ago|81 comments
28.
by mr_Fatalyst 1y ago
Hi all, About a month ago I shared FastOpenAPI on Show HN. The response was far beyond what I expected with thoughtful feedback, feature requests, technical questions and even a great PR. I tried to sum it all up in this write-up including
29.
by mr_Fatalyst 1y ago
Big thanks to everyone for the feedback and your reactions! I've started working on version 0.5.0 and will try to include as much as possible of what was highlighted here.
30.
by mr_Fatalyst 1y ago
I added the draft in 0.5.0-dev https://github.com/mr-fatalyst/fastopenapi/tree/0.5.0-dev Example: https://github.com/mr-fatalyst/fastopenapi/tree/0.5.0-dev/ex...

More ›