Live data from Hacker News

Show HN: Prisma Python – A fully typed ORM for Python

github.com

81–90 of 91 posts

Re: Show HN: Prisma Python – A fully typed ORM for Python

#81

Earlier quoted context omitted.

You can create Python types at runtime, and Python’s runtime type checking features predate it's static analyzers. Unfortunately, the additional kinds of objects used for typechecking in the static analyzers (beyond those which are also runtime types) don’t work with runtime type checking, nor do static type declarations (even using types that are also runtime types.) (And, obviously, AOT static analyzers can’t make…

I have also written a python ORM, Bozen[1]. In Bozen you define a table like this: class Book(MonDoc): title = StrField() yearPublished = IntField() Is it possible to give run-time types to `title` and `yearPublished`, in a way that works with mypy and the Python typing ecosystem? If so, is there a tutorial on this, as I'd like to add the feature to my ORM. 1: https://github.com/cabalamat/frambozenapp

The most obvious way would be to simply annotate the fields, e.g.

  class Book(MonDoc):
    title: str = StrField()
    yearPublished: int = IntField()
If this means too much redundant information for you then you could try defining the fields to return the corresponding python type e.g.

  def IntField() -> int:
    ...

Re: Show HN: Prisma Python – A fully typed ORM for Python

#82
post #74

I use Prisma and it’s far from perfect but what I love about it is you can introspect a legacy database and generate a Prisma schema, and use the database as the source of truth. You’re not tied to a 1:1 relationship between classes and tables, and the correctness of the types do not depend on tediously annotating code correctly. Excited to see more languages supported!

Are there any ORMs that do that currently? That sounds awesome

Entity Framework allows you to do that (if you are coding for .NET). It is the best ORM I've encountered.

The option to do it is called "Code First from Database".

Re: Show HN: Prisma Python – A fully typed ORM for Python

#83

Earlier quoted context omitted.

I find the relational API very easy and intuitive to work with. What do you not like about it?

So do I - the parent is choosing to compare the most basic example which didn't show the benefits of using an orm over raw sql

This is one of the things I've never understood about ORMs. They're not helpful for simple queries, but they're also not helpful for the most complex queries. When I've used ORMs in past (e.g., Active Record), we regularly needed to bypass the ORM to write raw SQL for complex queries in order to get the best performance.

Re: Show HN: Prisma Python – A fully typed ORM for Python

#84

How is this DSL acceptable? posts = await client.post.find_many( where={ 'OR': [ {'title': {'contains': 'prisma'}}, {'content': {'contains': 'prisma'}}, ] } ) SQL for comparison: ... where title like '%prisma%' or content like '%prisma%'

Try making an apples to apples comparison.

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.

Re: Show HN: Prisma Python – A fully typed ORM for Python

#85

Earlier quoted context omitted.

So do I - the parent is choosing to compare the most basic example which didn't show the benefits of using an orm over raw sql

This is one of the things I've never understood about ORMs. They're not helpful for simple queries, but they're also not helpful for the most complex queries. When I've used ORMs in past (e.g., Active Record), we regularly needed to bypass the ORM to write raw SQL for complex queries in order to get the best performance.

With Python and SqlAlchemy, I was surprised how intuitive some rather complex queries were to write and read, and by the quality of the generated SQL.

Re: Show HN: Prisma Python – A fully typed ORM for Python

#86
post #13

Nowhere is the acronym ORM explained, let alone how it can benefit Python programmers.

Presumably a lot of Python-developers already know what an ORM is and how they can benefit from it, in particular given how long SQLAlchemy has been around. The rest can presumably hit up their favourite search engine and type in 'ORM', hit 'Search' and learn quite quickly what it is.

> The rest can presumably hit up their favourite search engine and type in 'ORM'

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

Re: Show HN: Prisma Python – A fully typed ORM for Python

#87
post #74

I use Prisma and it’s far from perfect but what I love about it is you can introspect a legacy database and generate a Prisma schema, and use the database as the source of truth. You’re not tied to a 1:1 relationship between classes and tables, and the correctness of the types do not depend on tediously annotating code correctly. Excited to see more languages supported!

Are there any ORMs that do that currently? That sounds awesome

MikroORM can also auto generate schema from an existing database

Re: Show HN: Prisma Python – A fully typed ORM for Python

#88
post #74

Earlier quoted context omitted.

Are there any ORMs that do that currently? That sounds awesome

If you're wanting to automatically generate the Prisma Schema then all you have to do is create the schema file, define the datasource connection and then run `prisma db pull`

Indeed! https://www.prisma.io/docs/concepts/components/introspection

Re: Show HN: Prisma Python – A fully typed ORM for Python

#89

How is this DSL acceptable? posts = await client.post.find_many( where={ 'OR': [ {'title': {'contains': 'prisma'}}, {'content': {'contains': 'prisma'}}, ] } ) SQL for comparison: ... where title like '%prisma%' or content like '%prisma%'

How do you suggest to improve it?

Write SQL.

Re: Show HN: Prisma Python – A fully typed ORM for Python

#90

How is this DSL acceptable? posts = await client.post.find_many( where={ 'OR': [ {'title': {'contains': 'prisma'}}, {'content': {'contains': 'prisma'}}, ] } ) SQL for comparison: ... where title like '%prisma%' or content like '%prisma%'

Try making an apples to apples comparison. 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.

Bullshit. I don't need to use cursor with Python's sqlite3 module if I use the shorthand API exported by the module. I can write abstractions in Python. But I don't need to write shitty abstractions like the one for filtering.
Post reply on HN