I hate ORMs with the fury of a thousand suns. The problem is that I know SQL but now I have to spend a bunch of time trying to figure out how to convert SQL into ORM X just so it can convert it back to inefficient SQL. SQL mostly translates between various databases but ORMs are unique and you have to learn a new API for each one. I'm on a project using TypeORM and it has been fantastic at helping developers on my te…
DenoDB
51–60 of 220 posts
Re: DenoDB
#52The link and title made it seem like something official from the Deno developers but it's just a mirror for https://github.com/eveningkid/denodb
Re: DenoDB
#53Re: DenoDB
#54Earlier quoted context omitted.
You're being downvoted, but I completely agree. If you are on Node and Postgres I highly recommend using slonik - it makes it easy to just write SQL but at the same time makes it almost impossible to have mistakes like SQL injections: https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41... https://github.com/gajus/slonik
Along similar lines but more simple/agnostic, check out node-sql-template-strings[0] or sqlate[1]. [0]: https://github.com/felixfbecker/node-sql-template-strings [1]: https://github.com/moll/js-sqlate
Re: DenoDB
#55I hate ORMs with the fury of a thousand suns. The problem is that I know SQL but now I have to spend a bunch of time trying to figure out how to convert SQL into ORM X just so it can convert it back to inefficient SQL. SQL mostly translates between various databases but ORMs are unique and you have to learn a new API for each one. I'm on a project using TypeORM and it has been fantastic at helping developers on my te…
What's the alternative? Are you saying it's better to use raw SQL or to use your own home grown convenience functions for creating tables, selecting rows, etc.? And once you have the data from the SQL database are you keeping it just in arrays/dictionaries? Or should it at least be mapped to a class structure? As someone dealing with a bespoke SQL schema and mix of in-house SQL translation layers for different DBs, w…
Re: DenoDB
#56I hate ORMs with the fury of a thousand suns. The problem is that I know SQL but now I have to spend a bunch of time trying to figure out how to convert SQL into ORM X just so it can convert it back to inefficient SQL. SQL mostly translates between various databases but ORMs are unique and you have to learn a new API for each one. I'm on a project using TypeORM and it has been fantastic at helping developers on my te…
What's the alternative? Are you saying it's better to use raw SQL or to use your own home grown convenience functions for creating tables, selecting rows, etc.? And once you have the data from the SQL database are you keeping it just in arrays/dictionaries? Or should it at least be mapped to a class structure? As someone dealing with a bespoke SQL schema and mix of in-house SQL translation layers for different DBs, w…
I don’t consider it an ORM in the classical sense. I see it more as a query builder.
Re: DenoDB
#57I hate ORMs with the fury of a thousand suns. The problem is that I know SQL but now I have to spend a bunch of time trying to figure out how to convert SQL into ORM X just so it can convert it back to inefficient SQL. SQL mostly translates between various databases but ORMs are unique and you have to learn a new API for each one. I'm on a project using TypeORM and it has been fantastic at helping developers on my te…
You're being downvoted, but I completely agree. If you are on Node and Postgres I highly recommend using slonik - it makes it easy to just write SQL but at the same time makes it almost impossible to have mistakes like SQL injections: https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41... https://github.com/gajus/slonik
While I think this is totally the way to go, it is kind of amusing that PHP's PDO system was the "right" way to go all along in some ways
Re: DenoDB
#58Earlier quoted context omitted.
What's the alternative? Are you saying it's better to use raw SQL or to use your own home grown convenience functions for creating tables, selecting rows, etc.? And once you have the data from the SQL database are you keeping it just in arrays/dictionaries? Or should it at least be mapped to a class structure? As someone dealing with a bespoke SQL schema and mix of in-house SQL translation layers for different DBs, w…
I’ve been using https://prisma.io lately and I love it. It builds a Db client right from your db schema including Typescript typings. I don’t consider it an ORM in the classical sense. I see it more as a query builder.
Re: DenoDB
#59I have actually went back to writing pure SQL in files, and using those as params for whatever db engine i use, this makes it even possible to reuse the code in other projects (even its unlikely that you can use the exact same query, but just as a "it would work" in theory).
For node based projects i have used and would probably still choose pg-promise (https://github.com/vitaly-t/pg-promise).
Re: DenoDB
#60I hate ORMs with the fury of a thousand suns. The problem is that I know SQL but now I have to spend a bunch of time trying to figure out how to convert SQL into ORM X just so it can convert it back to inefficient SQL. SQL mostly translates between various databases but ORMs are unique and you have to learn a new API for each one. I'm on a project using TypeORM and it has been fantastic at helping developers on my te…
If you're using it to ad-hoc query your db then it's understandable you'll hate it - a leaky and poor abstraction over sql. Probably a bad fit.
Projects where I've seen it work well is when most of the logic is in the app with per row/per aggregate changes. In these apps it's only used for the "object relational mapping" side of things - ie to marshal types to/from db rows.
I've never found auto-migrations in ORMs good for anything less than a 1 day project - it's a world of hurt.