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

81–90 of 220 posts

Re: DenoDB

#81

Post by kaoD »

jakobdabo wrote: post #80
soylentgraham wrote: post #78

Earlier quoted context omitted.

If you omit await, the returned calue is a promise which you can keep for later, instead of waiting right now. Say you want to kick off something you know will take a while, do some ofher things (async or not), THEN wait for the original async operation. (Or even say, wait for multiple promises to finish)

Thanks, I understand it, but my issue is that more and more libraries and functions are now asynchronous, so the await prefix is going to be everywhere. Maybe it should've been the other way around - when calling an asynchronous function you get the result by default, and can get the promise if you want (as it happens much less frequently): const res1 = func1(); // async or not, wait for the result const res2 = func2…

If a function is async it's because it is potentially long-running or expensive. I don't want that fact hidden.

I don't find `await` particularly bothersome to write, and it explicitly tells me which calls are async and can be used in promise combinators or called non-blocking.

Re: DenoDB

#82

Post by lifthrasiir »

mozey wrote: post #70
threeseed wrote: post #64

Earlier quoted context omitted.

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

> And ORMs have the advantage of abstracting this SQL away for you allowing that you to work across databases if you need to In theory, in practise my experience is the oppose. It's easier to understand and tweak the SQL to work across DBs. You can easily diff and compare the SQL files. The ORM is another moving part, it adds convenience for simple queries, and complexity for anything advanced or non-standard.

SQL dialects vastly differ especially past SQL-92. And those differences tend to be very annoying (e.g. RETURNING). There is a reason that people do not generally work across different RDBMSes and instead pick and stick to a single RDBMS because it is really a PITA; I do dislike ORMs for usual reasons, but a bare SQL is not the alternative either.

Re: DenoDB

#83

Post by golergka »

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…

Have you tried pgtyped? I'm in love with it: it allows us check SQL queries at compile times and statically type them.

Re: DenoDB

#85

Post by viraptor »

ilovwindows wrote: post #84

ORMs are unnecessary abstraction. Check out https://github.com/ludbek/sql-compose Tools like this are the future. It's so simple yet flexible enough to handle any complex queries. It scales infinitely.

Query composing is probably 5% of the ORM framework. This is a valid thing to use. It's not an ORM replacement in any way.

Re: DenoDB

#86

Post by golergka »

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

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?

Re: DenoDB

#87

Post by golergka »

KingMachiavelli wrote: post #40
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…

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…

As I've already mentioned twice in this comment section, pgtyped and similar libraries. You wrote raw SQL, then they check it against a database at compile time and give you static types for your inputs and outputs.

Re: DenoDB

#88

Post by nine_k »

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 agree that ORMs have a very narrow area of applicability, at best.

OTOH I do appreciate when a library allows to construct SQL from first-class, reusable parts, like SQLAlchemy allows in Python. Using the same where-clause object in both select and update operations, or combining descriptively named filter clauses to create or amend a where clause, or easily constructing CTEe from other queries, etc — this all is pretty empowering, and, most importantly, expresses the logic better.

Re: DenoDB

#89

Post by jakobdabo »

kaoD wrote: post #81
jakobdabo wrote: post #80

Earlier quoted context omitted.

Thanks, I understand it, but my issue is that more and more libraries and functions are now asynchronous, so the await prefix is going to be everywhere. Maybe it should've been the other way around - when calling an asynchronous function you get the result by default, and can get the promise if you want (as it happens much less frequently): const res1 = func1(); // async or not, wait for the result const res2 = func2…

If a function is async it's because it is potentially long-running or expensive. I don't want that fact hidden. I don't find `await` particularly bothersome to write, and it explicitly tells me which calls are async and can be used in promise combinators or called non-blocking.

Thanks, I guess that's a good reason.

Re: DenoDB

#90

Post by kh_hk »

Is the general consensus that we are just happy slapping an 'await' in front of instructions we want to execute sincronously, or I am missing some fundamental idea here?
Post reply on HN