3 ms·
Like all alternatives to SQL I have seen, this is not as lean and readable as SQL.
by mg 2y ago
Like all alternatives to SQL I have seen, this is not as lean and readable as SQL.
- randomdata 2y agoThe SQL is preferable in this overly simple, cherry-picked case, but now do composition.
- pavel_lishin 2y agoI'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.)
- randomdata 2y agoI 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'))
- pavel_lishin 2y agoI 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 };
- mg 2y agoIt looks like "row" is already the object you want. Why make a copy of it? And why copy it by copying each property individually?
- pavel_lishin 2y agoRow is just a dumb object, without a type.
- mg 2y agoSo is the obj you created.
- pavel_lishin 2y agoAh, I meant to specifically decorate it as a Typescript object, but forgot to add it.
- dragonwriter 2y agoNo, "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.)