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

101–110 of 220 posts

Re: DenoDB

#101

Post by kristiandupont »

jeswin wrote: post #72
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…

If the programming language can offer type safety for queries, it's a big win. For instance in the .Net framework, Entity Framework continues to be the default choice after a decade because it is well integrated with the language and also allows you to use SQL if needed. Meanwhile in say JS, an ORM has less to offer. So really, just like most other programming decisions, the answer is "it depends".

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.

Re: DenoDB

#102

Post by wruza »

kaoD wrote: post #96
jakobdabo wrote: post #89

Earlier quoted context omitted.

Thanks, I guess that's a good reason.

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”.

Re: DenoDB

#103

Post by maple3142 »

flakiness wrote: post #6

Looking at the dependencies, I realized that it is now common to implement database bindings purely in the host language (vs. using vendor provided C/C++ SDK.) Deno PG [1] and MySQL [2] does it. This makes sense considering Deno's security model. But Node libs do the same [3][4]! This also kinda make sense, as node-based JS has to be async most of the time. Still it's such a hassle. Anyways, kudos to both communities…

I think one reason is using native C/C++ SDK makes it harder to install (compared to pure JavaScript/TypeScript), because you can't assume that compiler is always available. For example, you need to install extra tools to use install node modules with native dependencies on Windows.

Re: DenoDB

#104

Post by nicoburns »

threeseed wrote: post #64
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…

> SQL is universal No it's not. A small subset of it will work consistently across databases. But if you want to get the most of your database then in almost cases you will be working with proprietary SQL. And ORMs have the advantage of abstracting this SQL away for you allowing that you to work across databases if you need to.

True, but the only case where yoy really need to work across dbs is if you are creating a product that allows your customers to bring their own db. Otherwise you are much better off picking a db and sticking with it.

Re: DenoDB

#105

Post by OJFord »

supermatt wrote: post #98
nine_k wrote: post #91

Earlier quoted context omitted.

No, ORMs do much more. They turn slices of resultsets into objects. They lazy-load related objects instead of using one efficient join and doing one query; they in general have trouble representing results of projections and joins. They fetch all "attributes of the object" when you need to select a couple of columns from two dozen. They make the objects mutable, and introduce dirty state without transactional control…

Sounds like all your gripes are from a naive usage of ORMs. Rails ActiveRecord, for example, handles ALL your mentioned scenarios (includes, joins, select, Transaction.do, update_all - and you can still run SQL queries or fragments thereof). Theres a lot more in the docs than you will see in "toy examples". Of course, not all ORMs are created equally...

Not GP, and I've never used Rails so I'm not fanboying over it, but I've long had the impression that ActiveRecord is at least one of the most sophisticated ORMs; it wouldn't surprise me if it handles more complex cases better than others.

I think my preferred style (vs. full ORM or raw SQL) is that of Diesel (which is incidentally from a (former?) maintainer of ActiveRecord, Sean Griffin, though I think he may have since stepped back from it) for Rust - it's more like 'SQL bindings' than 'ORM's typically are or grow to be; so you pretty much write SQL, just in Rust syntax with type checking etc. instead of actual SQL in one big Rust string.

Re: DenoDB

#106

Post by madeofpalk »

kristiandupont wrote: post #101
jeswin wrote: post #72

Earlier quoted context omitted.

If the programming language can offer type safety for queries, it's a big win. For instance in the .Net framework, Entity Framework continues to be the default choice after a decade because it is well integrated with the language and also allows you to use SQL if needed. Meanwhile in say JS, an ORM has less to offer. So really, just like most other programming decisions, the answer is "it depends".

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"?

Re: DenoDB

#107

Post by f6v »

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 never shy away from complex SQL when it's warranted. But frameworks can make reading simple queries much easier, e.g. when using ActiveRecord in Rails. Readability is a big advantage in my book.

Re: DenoDB

#108

Post by williamdclt »

pjmlp wrote: post #49
Waterluvian wrote: post #25

Earlier quoted context omitted.

Why are you being forced to use ORMs if you don't want to and they're not the correct tool for the job?

When one is yet another cog on the machine, without any saying on the project technical directions.

...or when one is an empowered individual contributor yet doesn't have full decision power in the project technical direction. Other people also have opinions

Re: DenoDB

#109

Post by f6v »

threeseed wrote: post #64
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…

> SQL is universal No it's not. A small subset of it will work consistently across databases. But if you want to get the most of your database then in almost cases you will be working with proprietary SQL. And ORMs have the advantage of abstracting this SQL away for you allowing that you to work across databases if you need to.

It's always been the opposite for me. Whenever I had to use something PG-specific in Rails I had to resort to SQL.

Re: DenoDB

#110

Post by williamdclt »

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…

I mostly agree with you, but to be fair TypeORM is a particularly bad ORM.
Post reply on HN