Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DenoDB

github.com

Post reply on HN
Print view View original

181–190 of 220 posts

Re: DenoDB

#181

Post by hn_throwaway_99 »

girvo wrote: post #57
hn_throwaway_99 wrote: post #14

Earlier 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

> it makes it easy to just write SQL but at the same time makes it almost impossible to have mistakes like SQL injections 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

Meh, not really. Some of the biggest benefits from slonik are only possible because of Javascript's support for tagged template literals [1], e.g. you write a statement like

  sql`SELECT id FROM foo WHERE bar = ${barValue}`
Tagged template literals make it feel like you're just doing string concatenation, but it's done in such a way where under the covers it's actually creating prepared statements, and it is literally impossible to have SQL injection bugs unless you deliberately go out of your way to make them.

1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: DenoDB

#182

Post by hn_throwaway_99 »

golergka wrote: post #86
hn_throwaway_99 wrote: post #14

Earlier 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

Thanks for the link to the slonik, never heard about it before. But if I'm not mistaken, if doesn't generate types for result days from the queries, unlike pgtyped?

> But if I'm not mistaken, if doesn't generate types for result days from the queries, unlike pgtyped?

You are correct. But note that pgtyped is really only able to generate types because it actually needs to run your queries against a running instance of your DB. Some contributors have commented they are working on something similar for Slonik, https://github.com/gajus/slonik/pull/267#issuecomment-840559...

Re: DenoDB

#183

Post by dang »

bartlomieju wrote: post #135
dang wrote: post #37

Earlier quoted context omitted.

OK, we'll change to that from https://deno.land/x/denodb@v1.0.38 . Thanks.

https://deno.land/x/ is a service from Deno, but it's a registry for 3rd party modules. There's no need to change the URL

The HN guidelines ask "Please submit the original source. If a post reports on something found on another site, submit the latter," and I assume the github link is closer to being the original source.

https://news.ycombinator.com/newsguidelines.html

Re: DenoDB

#184

Post by halostatue »

brainless wrote: post #134

Every time we discuss an ORM project, someone is bound to complain about ORMs in general. I have a small suggestion: please try ORMs in different languages. A lot of the power of an ORM depends on the language. Your ORM may not be the same as my ORMs - Django ORM, SQLAlchemy, Pony ORM. Try them and you will know why. I will wait. From my limited understanding, the language needs to allow reflecting and manipulating y…

My biggest issue with _many_ ORMs don’t deal with production deployment as a thing but as an afterthought (I’m looking at _most_ of the JS ORMs for this nonsense; `.sync()` should _NOT_ be how you introduce database changes).

Early Rails got many things wrong from a DB perspective (what do you expect when MySQL is the baseline for capabilities?), but its insistence on using migrations from the first word was one of the best decisions ever made.

Re: DenoDB

#185

Post by tasuki »

SomeCallMeTim wrote: post #155
andrewmcwatters wrote: post #143

Earlier quoted context omitted.

For me, ORMs are a sign one isn’t comfortable reading and writing SQL. I think this happens because in so many projects, commercial and hobbyist, you write queries a few times and then forget about it. So, it’s totally understandable. I was there once. I’m very comfortable reading and writing basic SQL now, and so I’d prefer to think in SQL when working with a database, and think about objects when I’m in a programmi…

I am super happy and comfortable reading and writing SQL. Give me the slightest excuse and I'll write up a wicked complex query that does exactly what we need to solve a particular problem. I simply also feel that having 100% type safety in your results (which you really can't do with SQL queries) is a huge bonus. Add in database portability for most of your operations (including between, say, PostgreSQL and MongoDB)…

> I simply also feel that having 100% type safety in your results (which you really can't do with SQL queries) is a huge bonus.

It is possible to get type safety with SQL queries. Eg doobie[0], a purely functional JDBC layer for Scala.

[0]: https://tpolecat.github.io/doobie/

Re: DenoDB

#186

Post by g8oz »

Supermancho wrote: post #45
bjt wrote: post #44

Earlier quoted context omitted.

> What's the alternative? Not sure the parent comment would like it, but there's a middle ground between ORM and raw SQL that I consider a sweet spot. It's more of a "query builder" library that gives you language-appropriate constructs for building any SQL you like, but also provides more correctness guarantees than just writing raw SQL strings. SQLAlchemy's "expression" layer, for example, does this really nicely.…

There was a PHP library called NotORM which was great.

ezSQL is a similar project, also good.

Re: DenoDB

#187

Post by moltar »

dimitrios1 wrote: post #168
brainless wrote: post #134

Every time we discuss an ORM project, someone is bound to complain about ORMs in general. I have a small suggestion: please try ORMs in different languages. A lot of the power of an ORM depends on the language. Your ORM may not be the same as my ORMs - Django ORM, SQLAlchemy, Pony ORM. Try them and you will know why. I will wait. From my limited understanding, the language needs to allow reflecting and manipulating y…

Used ORMs in many different languages, from ActiveRecord, Hibernate, EntityFramework, SQLAlchemy, Bookshelf.js, GORM, and Ecto (Ecto was the best, ActiveRecord was the most "feature rich", Hibernate makes me cry, and EntityFramework is OK so long as you give Microsoft a lot of money). For dynamic languages the downsides are increased runtime cost over simply writing and executing sql and doing the mapping yourself, a…

Totally agree!

I come from the world of Perl, at the start of my career. Perl has DBIx::Class, still one of the best ORMs IMO.

I’ve transitioned via PHP and Laravel, which also has a decent ORM.

Nowadays I’m heavy into TypeScript and have tried every ORM there is in the JS/TypeScript land.

And I’ve settled on Zapatos, which is not an ORM, but exactly what you describe. It’s a utility that helps writing type safe and hinted queries.

This approach contrasted with, let’s say, TypeORM which is full of broken magic under the hood, is a breath of fresh air and is a delight to use.

Together with that I write simple repository wrappers manually and surprisingly there aren’t that many of them.

Re: DenoDB

#188

Post by djupblue »

phplovesong wrote: post #59

During my years as a dev i have really started to dislike ORMs. They always fail in the end. SQL is universal, and transfers between languages and tech fields. This is why im pro-sql, and always try to avoid unnecessary abstractions. I 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…

In my experience dealing with code written by people who only know ORM:s is about as fun as dealing with code written by people who refuse to use ORM:s when they really should have. The latter like to prove they don't need an ORM by creating their own "simple" libraries full of half broken functionality that pretty soon turns into to the ORM:s from hell.

Oh, be aware that SQL is not universal. Especially not if you do anything remotely advanced like triggers, non-trivial indexes or select queries that returns complex types.

Re: DenoDB

#189

Post by moltar »

smt88 wrote: post #161
SomeCallMeTim wrote: post #156

Earlier quoted context omitted.

Wow. See this other comment I wrote: https://news.ycombinator.com/item?id=27551288 TypeORM in particular is well designed and quite awesome. A huge benefit of TypeORM is that you get full static type support in all of your queries, including in the returned results. SQL results are effectively one-off dynamic type result piles that you need to validate by hand, and are insanely inefficient to code.

> A huge benefit of TypeORM is that you get full static type support in all of your queries, including in the returned results. When did I say I wanted to give up static typing? You can have both[1][2]. I would never give up static typing and would not have used Node if TypeScript/Flow were unavailable. > TypeORM in particular is well designed and quite awesome. I've used TypeORM extensively in production on multiple…

Zapatos ftw

Re: DenoDB

#190

Post by ttfkam »

hn_throwaway_99 wrote: post #14
Osiris wrote: post #12

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…

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

I prefer the postgres module. 0 dependencies. Easy to use API. Wicked fast. Also really hard to fall victim to SQL injection attacks unless you actually put some extra effort into doing something foolish.

https://github.com/porsager/postgres#readme

Post reply on HN