Aside from static type checking, providing type hints means that you will get autocomplete suggestions for you which for me is the killer feature for this ORM (see the GIF in the README for an example).
It's also built on top of Prisma, a next-generation ORM for TypeScript which means that the core query building and connection handling has been battle tested, getting around a potential concern with adopting a new ORM.
Prisma Python also supports PostgreSQL, SQLite, MongoDB, MariaDB and more!
posts = await client.post.find_many(
where={
'OR': [
{'title': {'contains': 'prisma'}},
{'content': {'contains': 'prisma'}},
]
}
)
... where title like '%prisma%' or content like '%prisma%'You neglected to write the SELECT, which would typically not be as simple as "SELECT * from post".
You neglected to write the code to iterate over the results, which is trivial in the ORM version. In the SQL version it requires cursors and the error-prone manual mapping of positional data to named data.
Has a clear link to the python "any" as well
The option to do it is called "Code First from Database".
I'm assuming you are using a code generator? My understanding is that as MyPy is a static analyser there is no way to automatically create types at runtime (which is actually super annoying, particularly for a language as dynamic as Python).
It unfortunately leaves you with a choice of either taking advantage of dynamic annotations or using MyPy, but not both.
And as the sibling comment says, typescript did it so much better.
class Book(MonDoc):
title = StrField()
yearPublished = IntField()
The rest can presumably hit up their favourite search engine and type in 'ORM', hit 'Search' and learn quite quickly what it is.
Thats missing the point quite badly. You don't want anything in the opening sentence of you site triggering users navigating away / switching to another browser tab
Though to add to another comment, this is pretty basic in the CRUD and front-end world, and learning how to learn when confronted with unfamiliar information is a very useful life skill.
From [1]: "SQLModel is a library for interacting with SQL databases from Python code, with Python objects. It is designed to be intuitive, easy to use, highly compatible, and robust.
SQLModel is based on Python type annotations, and powered by Pydantic and SQLAlchemy."
statement = select(Hero).where(Hero.age > 32).limit(3)
But I am only halfway through the tutorial so I might be wrong.
HN discussion of SQLModel here [1]
Prisma looks nice. Is it a solo project mostly? Or is there a company paying for your time to spend on this ORM? To me it is very important that such an important module as an ORM will have support for the lifetime of an application. Or at least when the app is still being developed.
Autocomplete is the big one as it lessens the learning curve immensely. You no longer have to search through documentation to find a relevant method, you simply have to trigger autocomplete and it'll show you what you can do!
An example of this approach is PureORM[0]
Luckily, they are better implemented at my current job. I still think it gets in the way quite often, but I recognize that it enables some outsized returns on effort. Entire REST APIs can be generated with things like Spring Data. SqlAlchemy can be pretty slick in Python.
I still write raw SQL on my personal projects, but I recognize that I have to spend a lot of time doing that.
I'll probably oppose introducing a different Python ORM at work until Prisma Python reaches 1.0
Yeah that is understandable, it is being successfully used in production but it is safer to use a more stable ORM for mission critical products.
If you don't want to have to duplicate your model definitions you could write a custom Prisma Generator to generate models for a different Python ORM.
https://prisma-client-py.readthedocs.io/en/stable/reference/...
ORMs have the ability to work with multiple RDBMS implementations, but for that they trade away expressive power and efficiency. Prisma is fairly slow, especially when your query is fetching multiple relationships, because it does multiple DB roundtrips to fetch parts of the result and reconstitutes it on the client. ORM APIs are generally very limiting, as there is no general way of doing server-side computation (e.g. do a comparison on a substring of a string property or simply do arithmetic).
EdgeDB does not have these problems, because its query language, EdgeQL, is designed to be efficiently embeddable into a programming language without any loss of expressive power or performance. At this moment we have a fully-featured TypeScript/JavaScript builder [1], with Python and Go coming soon.
[1] https://www.edgedb.com/docs/clients/01_js/index#the-query-bu...
(Full disclosure: I work on EdgeDB)
Question: The Readme says there's room for massive improvement in performance. What's the performance like right now? Any benchmarks?
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.
How come GitHub doesn't highlight any Rust code in the project repo?
We (Prisma) would love to support this project in any way we can. You can find my email in bio if you are interested in a call :-)
> under the hood @prisma/client was spinning up it's own GraphQL server that it would send requests to in order to generate SQL to send to postgres[1]
So is this the same approach you are taking with the HTTP API?
I think it makes it such an easy onramp to integrate with something by having HTTP based APIs (or really, gRPC, even) even if it is lower performance compared to native libraries.
Looking forward to trying this.
Can I suggest you put this at the top of your README.md file, as I had never heard of Prisma before and it would have helped.
> Prisma Python
Is your program called Prisma Python or Prisma Client Python? You seem to be inconsistent with naming.
> Prisma Python
I originally decided to go with Prisma Client Python however I found this to be too verbose and have recently used Prisma Python. I do need to decide on one and stick with that. Thanks for pointing that out
It would be great if Prisma could support yet more languages! It's a great product.
That said, I would not have two backends sharing the same database, even if one is the master that runs migrations. A component should only have one reason to change.
SQLAlchemy on the other hand provides very little (if any) type hints for their query API.