71–80 of 91 posts
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 does Prisma compare to EdgeDB? Pros and cons? I have limited experiences with DBs and ORMs, but EdgeDB looks very interesting.
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?
Has a clear link to the python "any" as well
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!
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
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
How does Prisma compare to EdgeDB? Pros and cons? I have limited experiences with DBs and ORMs, but EdgeDB looks very interesting.
I am not very familiar with EdgeDB but it is quite different to Prisma. EdgeDB is a database while Prisma is a database client. EdgeDB do provide their own clients to interface with the EdgeDB database but with Prisma you can connect to many different databases, e.g. PostgreSQL, SQLite, MongoDB etc
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)
Earlier quoted context omitted.
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
https://github.com/RobertCraigie/prisma-client-py/issues/293
Earlier quoted context omitted.
How do you suggest to improve it?
I think the parent is saying that the SQL example is simpler and easier to read.
> by auto-generating python types 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).
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…
class Book(MonDoc):
title = StrField()
yearPublished = IntField()