Hacker News Reader

Comment by inshadows | Hacker News Reader

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%'

View on HN

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.

Haven’t used prisma but I think their query builder type checks (not just the results) which make composing and writing them quite a bit more convenient than the example shows.

Now try filtering on a relation!

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

Ah sorry I misread your comment, I thought you were agreeing and saying that filtering by a relational field is also unacceptable DSL.

Thank you :)

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.

How do you suggest to improve it?

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.

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

Write SQL.

Reply on news.ycombinator.com