How do you suggest to improve it?

Not the original author, but "or" at the start then a list may be better called "any". That (to me) would read more clearly. Particularly if you were passing in the contents, '"or": var' would make me think "var or what?" But '"any": var' seems more obvious.

Has a clear link to the python "any" as well

Thanks for the suggestion, I've created an issue to track this as I do agree that `ANY` conveys the operation more clearly.

https://github.com/RobertCraigie/prisma-client-py/issues/293

I think the parent is saying that the SQL example is simpler and easier to read.

Yeah, but he’s completely skipping over the fact that you’re going to lose some of the readability of short SQL statements switching to an ORM with methods, types/classes, functions, etc., but you can gain in maintainability of code.

Write SQL.

Use whatever works for you! I personally felt the same until I learned of Prisma. The main benefits for me are type checking and autocomplete.

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!

Thank you for sharing! It is much appreciated!

Also, the ticket I opened was promptly replied to and politely closed. This is actually an issue already open under this ticket:

https://github.com/prisma/prisma/issues/2879

Yeah, sharing the same database between two backends would not be a good idea. That said you do not have to use the TypeScript client at the same time as the Python client, they are independent of each other.

Yes I am using the same approach however I am working on using native FFI bindings which is what the TypeScript client is using now.

https://github.com/RobertCraigie/prisma-client-py/pull/165

That's great.

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.

There is actually an escape hatch you can use, although it is a bit clunky:

    ```py
    from typing import TYPE_CHECKING

    if TYPE_CHECKING:
        Foo = "expression that mypy can understand"
    else:
        Foo = "dynamic expression"
    ```

Somehow in all my searching the other day I missed that, thanks!

Thank you! I hope so too, it would be incredibly helpful.

This is really cool!

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 :-)

Yes it is rather unfortunate, Python's typing system doesn't support dynamically creating types like you can in TypeScript :/

> dynamically creating types

Could you explain what you mean by this? I'm not clear on what typescript behavior this describes.

Maybes mapped types are an example? https://www.typescriptlang.org/docs/handbook/2/mapped-types....

Yes mapped types is a good example, Pick is also a good example:

https://www.typescriptlang.org/docs/handbook/utility-types.h...

Ah, I read "dynamic" as implying something at runtime. I agree that these are extremely useful.

Yes it is similar to SQLModel however as SQLModel is based off of SQLAlchemy, the query API is not typed. That is the difference.

My understanding is that this is exactly what SQLModel adds on top of 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]

[1] https://news.ycombinator.com/item?id=28294534

My understanding of SQLModel is that it brings the benefits of both Pydantic and SQLAlchemy. The benefit of merging Pydantic with SQLAlchemy is that you can then use the database models directly in FastAPI route definitions.

AFAIK SQLAlchemy 2.0 (coming soon?) will use a new system for full typing.

Yes I had heard about that but due to the nature of Python typing, they can't actually type the query API properly without falling back to Any, negating the benefits of type checking.

The creator of sqlmodel seems to be very busy with fastapi and other projects. Only so much you can do in a day, so progress is slowed down by that.

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.

Unfortunately this is a solo project, however I am in communication with the Prisma team and the core engine that Prisma Python uses is backed by Prisma.

Yes it is fully typed because of TypedDicts, https://docs.python.org/3/library/typing.html#typing.TypedDi...

SQLAlchemy on the other hand provides very little (if any) type hints for their query API.