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

41–50 of 220 posts

Re: DenoDB

#41

Post by woutr_be »

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 use TypeORM quite often, especially in projects with fairly simple queries. But I always make it a point to:

* Write migrations first, so that you define your own schemas

* Disable TypeORM synchronize, make your migrations the source of truth instead of the entities

* Model your entities after your schema

Re: DenoDB

#42

Post by vinkelhake »

I've been using [1] which is SQLite compiled to WASM (what a weird world we're in now). It's got some limitations and caveats, but it's working well for my current modest needs. It's a pretty straightforward wrap of the SQLite API - no ORM. The advantage is that it doesn't depend on having anything installed. Just import and you're good to go.

[1] https://deno.land/x/sqlite@v2.4.2

Re: DenoDB

#43

Post by OJFord »

nemo1618 wrote: post #19
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…

> the fury of a thousand suns off topic, but I recently learn that this phrase dates back to the Bhagavad Gita! If the radiance of a thousand suns Were to burst at once into the sky That would be like the splendour of the Mighty One

How literally was that translated though? Ngram viewer shows [0] plenty of usage of 'of a thousand suns' well before that 1944 translation [1], though it certainly picked up after that, no doubt helped by Oppenheimer quoting it (that translation specifically, recently published at the time) w.r.t. the Manhattan project.

Confusingly [1] links to the passage in a different (1909-14) translation [2] which features the 'of a thousand suns' part but is otherwise different.

I just wonder, for example if the original was something like लक्षाणाम् सूर्याणाम् 'lakshāñām sūryāñām' (I think that's what I mean, I'm learning Hindi not Sanskrit! Just looking up लाख & सूरज roots.) but translated to 'thousand' on the basis that it just meant 'a lot', and that sounded better in English and was perhaps even already a phrase.

I don't mean to doubt you, just thought it was interesting, and translated texts are a bit of a can of worms.

[0] - https://books.google.com/ngrams/graph?content=of+a+thousand+...

[1] - https://www.bartleby.com/73/123.html

[2] - https://www.bartleby.com/45/4/11.html#44

Re: DenoDB

#44

Post by bjt »

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…

> 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. It existed long before the higher "ORM" layer came along, and can be used without having to touch the ORM.

In Go, I like the Goqu library for the same purpose.

In Rails land, my understanding is that the underlying Arel layer is more like this pattern, as opposed to the higher level Active Record ORM.

In Java, it's jOOQ instead of Hibernate.

Re: DenoDB

#45

Post by Supermancho »

bjt wrote: post #44
KingMachiavelli wrote: post #40

Earlier 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…

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

Re: DenoDB

#46

Post by pininja »

mcintyre1994 wrote: post #34
thegagne wrote: post #31

Earlier quoted context omitted.

I think it’s because of the different actions you might want to take after the fetch. 1. Parse the data as json 2. Return it without parsing 3. Modify some other part of the response but never parse the body 4. Turn around and stream that body into another fetch without parsing it. Etc. parsing it and loading a large response into memory may not always be desirable so it must be explicitly done with await res.body.js…

I agree that it might never be parsed/you might not want to, and that it shouldn’t be done implicitly. But I’m not sure why that requires await instead of just a plain function call to parse it explicitly.

Parsing JSON is synchronous, but fetch itself doesn’t read the body data.

> [1] to parse the body as JSON, first the body data has to be read from the incoming stream. And, since reading from the TCP stream is asynchronous, the .json() operation ends up asynchronous.

[1] https://stackoverflow.com/a/59555579

Re: DenoDB

#47

Post by smt88 »

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've been using pgTyped in production for months and it has been phenomenal.

There's another one called (I think) Zapatos that has some similar qualities.

Re: DenoDB

#48

Post by pjmlp »

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…

It was already common with Java and .NET, hence why the vocabulary types define multiple levels for the database drivers.

For example with JDBC:

Type 1 driver - JDBC-ODBC bridge

Type 2 driver - Native-API driver

Type 3 driver - Network-Protocol driver (Middleware driver)

Type 4 driver - Database-Protocol driver (Pure Java driver) or thin driver.

Most modern drivers are all type 4.

Re: DenoDB

#49

Post by pjmlp »

Waterluvian wrote: post #25
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…

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.

Re: DenoDB

#50

Post by younepen »

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…

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

Modern SQL has functions that can be used to map rows into json objects and arrays. That is what I use in nodejs/postgres. Everything is returned in the structure I want it in. The node driver turns the json into javascript arrays and objects (which then get turned back into JSON to send to the client, hah!). I added some code to the driver so that snake case field names are converted to camel case.

Post reply on HN