Re:Show HN: Prisma Python – A fully typed ORM for Python
by anentropic on Monday February 21, 2022 @11:44AM
(#30417796)
What is the Rust engine doing here?
How come GitHub doesn't highlight any Rust code in the project repo?
Re:Show HN: Prisma Python – A fully typed ORM for Python
by joshribakoff on Monday February 21, 2022 @02:11PM
(#30419453)
Prisma uses rust for two main reasons from what I understand. 1) to keep the engine portable and maximize code reuse, to make projects like this Python adapter possible for example 2) under the hood Primsa does not use joins. It does a waterfall of queries (but not n+1), then stitches the data together in memory, which happens in the rust engine for performance reasons
Re:Show HN: Prisma Python – A fully typed ORM for Python
by probablyrobert on Monday February 21, 2022 @11:47AM
(#30417827)
Because Prisma Python currently interfaces with the Rust engine over HTTP (I am looking into changing this) and the Rust engines can be found here:
Re:Show HN: Prisma Python – A fully typed ORM for Python
by bb88 on Monday February 21, 2022 @01:46PM
(#30419218)
Given the state of PyPi these days and third party packages, I would just prefer to have pure python, even if it is slower.
It means I don't have to worry about things breaking on cross compilation between mac/windows/linux.
Re:Show HN: Prisma Python – A fully typed ORM for Python
by probablyrobert on Monday February 21, 2022 @02:05PM
(#30419405)
No need to worry, the current behaviour will be preserved :)
The method used to interface with the internal engine will be able to be configured in the schema: https://www.prisma.io/docs/reference/api-reference/prisma-sc...
The biggest blockers in terms of performance are:
- Communication with the internal Rust engine is performed over HTTP instead of FFI.
- You cannot select a subset of fields (every scalar field in a model is selected)
- You cannot skip pydantic validation which while fast is unnecessary in some cases
With that said Prisma Python should be reasonably fast but I would expect it to be on the lower end of the spectrum compared to other Python ORMs. I have ran some load tests locally and creating 500,000 records took about 90 seconds.