Hacker News Reader

Comment by mg | Hacker News Reader

Like all alternatives to SQL I have seen, this is not as lean and readable as SQL.

I totally agree - but this has the advantage of returning something like a well-defined object that hews to an interface, as long as you have the model set up.

The trade-offs are usually worth it, vs, doing something like:

  const row = db.query('select whatever from wherever');
  const obj = {
    id: row.id,
    brand: row.brand,
    ... etc
  };

It looks like "row" is already the object you want. Why make a copy of it? And why copy it by copying each property individually?

Row is just a dumb object, without a type.

So is the obj you created.

Ah, I meant to specifically decorate it as a Typescript object, but forgot to add it.

No, "row" is a generic type, all concrete rows have concrete types narrowing the generic type with an ordered sequence of element tags and element types. (Relations are typed similarly to rows, since they are containers for rows of homogenous type.)

The SQL is preferable in this overly simple, cherry-picked case, but now do composition.

I've done composition in Objection ORM, and honestly, it's a fair amount of hassle.

On our projects, which are moderately small, I genuinely don't know if it is/was worth the hassle of setting up, vs. writing some repeated code. (We also have a pretty decent testing culture in place, so I would be much more accepting of DRY-violations.)

I assume the above is based on said package? Wherein lies the hassle?

    bmws = Cars.query().where( { brand: "BMW" }).groupBy('year').orderBy('year')
    bmwAvg = bmws.select(avg('price'))
    bmwMin = bmws.select(min('price'))
    bmwMax = bmws.select(max('price'))

Reply on news.ycombinator.com