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

111–120 of 220 posts

Re: DenoDB

#111

Post by deergomoo »

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…

I've been keeping one eye on EdgeDB [0], which I believe could remove a lot of the desire for ORMs. In my experience a lot of the drive behind ORM use is that SQL kinda sucks at returning anything that looks vaguely like a tree.

For example, with SQL if you wanna load all a list of Users, and all those User's Posts, and the Thread that post was made in, you're either doing joins and some awkward transposition of the flat data into a tree, or you're doing three queries and looping through the data sets to join everything up by hand. When you have an ORM that lets you do `User::with('posts.thread')->get()`, it's easy to become reliant on it and never really dig into what's happening.

With EdgeDB, everything is a set. Retrieving a set of Users where each has a set of Posts where each has a set (of one) Threads becomes something where the database layer is pretty much a 1:1 mapping to your program's data structures, but with all the benefits of an RDBMS.

Considering insertions and updates also use sets, I could envision replacing an ORM with an ultra-thin layer that essentially just converts back and forth between trees of records and EdgeQL sets. As you might imagine this is very nice for GraphQL too.

Take this with a pinch of salt as I've only done the most basic playing around with it, but it certainly seems like an interesting idea.

[0] https://www.edgedb.com/docs/tutorial/queries

Re: DenoDB

#112

Post by eterps »

deergomoo wrote: post #111
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…

I've been keeping one eye on EdgeDB [0], which I believe could remove a lot of the desire for ORMs. In my experience a lot of the drive behind ORM use is that SQL kinda sucks at returning anything that looks vaguely like a tree. For example, with SQL if you wanna load all a list of Users, and all those User's Posts, and the Thread that post was made in, you're either doing joins and some awkward transposition of the…

Wow that looks great, thanks!

Re: DenoDB

#113

Post by lyind »

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…

I have reached the same conclusion regarding ORMs after strugling with Hibernate/JPA for some time.

At least for Java and Kotlin the awesome library jdbi ( https://jdbi.org/ ) implements a very useful hybrid approach.

One creates DAOs and Repositories to abstract away the DB and map results and arguments to/from objects on the fly. All while retaining full control over the SQL and all mapping aspects.

This way SQL and mapping can be optimized to leverage the features of each database (ie. PostgreSQL's array, UUID, hash and JSON types) or be handled generically.

The SQL loading can also be customized to read SQL from pure ".sql" files in resources/files or from inline specification via annotations.

The jdbi developers have in the past reacted very fast and competent to issue reports or PRs.

If find applications built using this library more easy to understand and also better performing than ones using a full-blown ORM.

Re: DenoDB

#114

Post by kaoD »

wruza wrote: post #102
kaoD wrote: post #96

Earlier quoted context omitted.

Another reason: when you `await` a promise your function pauses until promise resolution and other code will run meanwhile. In contrast, since JavaScript is single-threaded, calling synchronous functions means only that function will be run and will immediately return to your code, with nothing else happening in-between. The semantics are very different. Implicit `await` will quietly introduce this concurrency point,…

It is okayish in TypeScript, but in js one subtle missing await also leads to unexpected everything. Mass-await in a language without types is a bad idea generally, but we have no alternatives for “the web”.

It's not a problem with types. It's a problem with call semantics.

If `foo()` behavior depends on whether `foo` is async or not, you're implicitly introducing yield points that might lead to bugs like race conditions.

Even worse: if you're calling a sync function and you (or a library author) turns it into an async function, it will silently introduce the yield point without anybody noticing.

Both sync and async `foo()` would return a `T` so TypeScript won't help with that.

Re: DenoDB

#115

Post by kristiandupont »

madeofpalk wrote: post #106
kristiandupont wrote: post #101

Earlier quoted context omitted.

I generate Typescript types directly from a Postgres database. That works great with Knex and a bit of custom code I've written on top.

How do you know you're saving and retrieving data that correctly matches your typescript definition? Or are you just saying "trust me"?

Knex has some built-in support for it, but I've made a wrapper that does it quite well. So I can write db.select('member', { displayName: 'John' }) -- and because I specify the table name in the first parameter, I get type checking on the second.

Re: DenoDB

#116

Post by elliebike »

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…

I always feel weird about comments like this. Instead of discussing the merits of the actual project shared, we're going on a rant about whether or not ORMs are a good idea?

It's like whenever someone shares something they made with Electron, and the comments are just Electron hate.

Re: DenoDB

#117

Post by phplovesong »

deergomoo wrote: post #111
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…

I've been keeping one eye on EdgeDB [0], which I believe could remove a lot of the desire for ORMs. In my experience a lot of the drive behind ORM use is that SQL kinda sucks at returning anything that looks vaguely like a tree. For example, with SQL if you wanna load all a list of Users, and all those User's Posts, and the Thread that post was made in, you're either doing joins and some awkward transposition of the…

Never seen edgedb before. Ill have a look, thanks for the tip.

I usually find the docs always giving a super trivial example. Like a join. Joins are the bread and butter of database work, and design. You model your data and write queries that operate on it.

When it comes to real-world things, i usually do complex reports that include joins from aggregated sets on some condition. Here is where the orms fail big time. Edgedb seems to be build on postgres, so does it come with the same power or is the new syntax limited in some way?

Re: DenoDB

#118

Post by furstenheim »

elliebike wrote: post #116
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…

I always feel weird about comments like this. Instead of discussing the merits of the actual project shared, we're going on a rant about whether or not ORMs are a good idea? It's like whenever someone shares something they made with Electron, and the comments are just Electron hate.

Not really, Electron would be the tool but not the end goal. Here an ORM is the end goal and that's what the parent complains about.

Re: DenoDB

#119

Post by zomglings »

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

The "Stop using knex.js" blog post misses a very important point in favor of using knex.js: database migrations.

Migrations allow a development team to synchronize database schema changes across multiple branches of development.

It is the main reason I end up using tools like knex.js (node) and sqlalchemy (python).

As far as knex is concerned, you can use it to manage migrations without using it in your application code.

Re: DenoDB

#120

Post by qeternity »

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…

I'd tend to agree with you in javascript-land, but the Django ORM is black magic...the (mostly) performant and complex queries you can build with it are simply amazing. Add in the migration system, and it's really tough to complain, especially since you can always drop into raw sql as needed.
Post reply on HN