A farewell to ORMs - Colin McDonnell | EdgeDB Day
HTML-код
- Опубликовано: 13 сен 2024
- How EdgeDB obviates the need for ORMs, plus an introduction to our typesafe EdgeQL query builder for TypeScript. By Colin McDonnell.
Slides: www.slideshare...
Twitter: / edgedatabase
Discord: / discord
Website: edgedb.com
This is exactly what I need
Would love an explanation (or link to a github issue) for the problem that happened at the end of the demo. While I love EdgeDB approach, these sorts of issues makes me nervous about experimenting with it at this stage.
Good explanations and amazing intellisense, can't wait to try
I'm really sorry for what i'm about to say, but why sound quality is so bad? Pleeeease it's 2022 already. Fix the sound at last!
Going to check this. Important is, expression constraints that are detailed are only good if you can use the schema as model without limitations and the errors produced can be used for client, otherwise you have to duplicate code validation and database validation in two different languages.
I'm ok with coupling the model of app to the edgedb, as from my experience I never had to switch dbs in a single app, so I don't need the flexibility.
I don't like prisma overall, even if it has some nice things. Its in my eyes not really an ORM compared to other languages, its more a db schema generator and migrator and typed query builder generator (the rly good part). You can't really model something meaningful with it. It limits what you can do with the underlying DBS severely.
The choice to go with own DSL, contrary to using code is that you need a very powerful one to cover all the things one could abstract with code. The DSL of prisma is very simple and weak and you can't even reuse fragments. You could do it, if you could write the schema with code. DSL is more convenient to use, but it needs to cover very many cases to be any meaningful. EdgeDB seem to have more powerful and detailed one. But obviously I will need to evaluate it more deeply.
Judging by the fact you can index the computed property, the computation must be write-time? That means it needs to be part of migration when you change it. I can't imagine this to be automated, so I guess you can do it similar to ORM migrations, by generating the schema changes and adding dm queries to update stored data?