Live data from Hacker News

DenoDB

github.com

31–40 of 220 posts

Re: DenoDB

#31

At first glance -- async/await mitigates a lot of my least favorite things about orm dsl's -- namely that it can be difficult to tell when the orm framework is actually going to generate a db round trip without being familiar with the implementation ... thinking back to the most recent orm i had to learn (rails) and how it was quite annoying to get started with while interacting with an existing codebase. clear suspe…

This doesn’t always work with Node APIs, one example that comes to mind is fetch (for making URL requests). When you await a fetch(url) you get a response object, where a bunch of functions on it (like json() IIRC) are themselves promises - but not making another API call. I’m not actually sure why it’s structured like that, I guess to give unified error handling/callback syntax between the call failed and the unexpe…

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.json().

Re: DenoDB

#32
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…

Where I'm at now, we have a big huge Java app that uses MyBatis (https://mybatis.org/mybatis-3/)

It involves writing SQL inside of XML files and doing a lot of manual mapping from columns back to the objects.

At first I REALLY disliked it but over time I have grown to absolutely love being able to just write SQL queries that can return whatever. Writing raw SQL really lets you optimize and create complex queries when you need to in a way that you can't with an ORM.

Re: DenoDB

#33
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…

Check out slonik if you want something that does not go full pg-types. I combine it with io-ts for runtime validation.

Re: DenoDB

#34

Earlier quoted context omitted.

This doesn’t always work with Node APIs, one example that comes to mind is fetch (for making URL requests). When you await a fetch(url) you get a response object, where a bunch of functions on it (like json() IIRC) are themselves promises - but not making another API call. I’m not actually sure why it’s structured like that, I guess to give unified error handling/callback syntax between the call failed and the unexpe…

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.

Re: DenoDB

#35
post #27

Really dislike active record style ORMs. Even if the entities are proxies w/ some magic (e.g. lazy loading), they should still read like plain records in the code, and be programmed with a data-first style. Because methods accumulate on these active record entities, I’ve found devs tend to treat them more “thingly” than just data projections. The user doesn’t save itself. It’s just a row in a database.

I agree.

The one thing that keeps bringing me back to ActiveRecord and ORMs like it is the Relation class. Being able to pass around and merge queries is great for organizing code and keeping concerns separate. For example, implementing pagination, user permissions, UI filtering, and tenant segmentation, all in the same query without these concerns depending on each other. Composable scopes on models is another joy.

One convenient trick with Postgres is to define complex calculations as SQL views. Define an ActiveRecord model for the view, point some “summary” associations at it, and read it like a table.

Re: DenoDB

#36
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

If I remember well was a phrase used by Oppenheimer about the atomic bomb, a sentence that he read from Bhagavad Gita.

Re: DenoDB

#38
You can't yet have multiple where conditions seperated by an OR operator. I've been using this library for a side project and unfortunately I just don't think it's mature for production use cases yet.

Hopefully it keeps maturing as it otherwise shows quite a bit of promise.

Re: DenoDB

#39
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…

Have you tried Ruby on Rails' ActiveRecord? I like it! It's easy to use and easy to integrate with "raw sql" if needed.

Re: DenoDB

#40
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, wrapper functions... I would think any ORM would be better designed since it has a singular purpose and database experts work on their development.

Post reply on HN