4 ms·

> const selectBy = (table, column, value) => db.query(`SELECT * FROM :table WHERE :column = :value`, {table, column, value}) > const selectOneBy = (table, colu

> const selectBy = (table, column, value) => db.query(`SELECT * FROM :table WHERE :column = :value`, {table, column, value}) > const selectOneBy = (table, column, value) => { const res = selectBy(table, column, value); return res && res.shift() } Two or three lines gives you about 80% of the value in any ORM and avoids the -20% value found in the other 100k LOC.

idoubtit 8y ago
> Two or three lines gives you about 80% of the value in any ORM and avoids the -20% value found in the other 100k LOC. I have a hard time believing this when the two lines above are obviously wrong. You can't use :column to escape the name of a column in SQL. So your code has to protect it, which is not easy if you wan't to be portable. MySQL will generally use `column` but may be configured to use the standard "column". Anyway, selectAllBy() and selectOneBy() are not enough to be confortable. I appreciate the static completion in Something.find({id: 1}).complete, the relative queries like Post.find({id: 1}).author, and many other things that help against typos, help code faster and make the code more readable. I agree with the OP that fallthroughs are much needed, because writing custom SQL is sometimes simpler, and sometimes much more performant. Usually, its mostly about writing SomeModel.findAllBySql() which most ActiveRecord implementations provide.
- saas_co_de 8y ago
  > the two lines above are obviously wrong there is something called psuedo code. use your imagination. > Anyway, selectAllBy() and selectOneBy() are not enough to be confortable Like I said: 80%. > SomeModel.findAllBySql() which most ActiveRecord implementations provide So you are arguing that you should use a huge ORM code base, full of bugs, but then don't use it for anything complex, which means don't use 80% of the code, which is what "handles" all those complex edge cases. Except then you have to have your team agree on what "complex" is, and half the team (who don't actually code anything complex) argue that you should use the ORM for everything, and then you end up in the sh-tshow that most amateur shops that build on ORMs are in. Bottom line, ORMs are for low skill teams that basically don't know what they are doing, and if they ditched the ORM they might actually be able to learn to code decent systems.
  - dang 8y ago
    Please don't cross into incivility when commenting here, regardless of how right you are or feel you are. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
deleted 8y ago
[deleted]

idoubtit 8y ago

> Two or three lines gives you about 80% of the value in any ORM and avoids the -20% value found in the other 100k LOC. I have a hard time believing this when the two lines above are obviously wrong. You can't use :column to escape the name of a column in SQL. So your code has to protect it, which is not easy if you wan't to be portable. MySQL will generally use `column` but may be configured to use the standard "column". Anyway, selectAllBy() and selectOneBy() are not enough to be confortable. I appreciate the static completion in Something.find({id: 1}).complete, the relative queries like Post.find({id: 1}).author, and many other things that help against typos, help code faster and make the code more readable. I agree with the OP that fallthroughs are much needed, because writing custom SQL is sometimes simpler, and sometimes much more performant. Usually, its mostly about writing SomeModel.findAllBySql() which most ActiveRecord implementations provide.

saas_co_de 8y ago
> the two lines above are obviously wrong there is something called psuedo code. use your imagination. > Anyway, selectAllBy() and selectOneBy() are not enough to be confortable Like I said: 80%. > SomeModel.findAllBySql() which most ActiveRecord implementations provide So you are arguing that you should use a huge ORM code base, full of bugs, but then don't use it for anything complex, which means don't use 80% of the code, which is what "handles" all those complex edge cases. Except then you have to have your team agree on what "complex" is, and half the team (who don't actually code anything complex) argue that you should use the ORM for everything, and then you end up in the sh-tshow that most amateur shops that build on ORMs are in. Bottom line, ORMs are for low skill teams that basically don't know what they are doing, and if they ditched the ORM they might actually be able to learn to code decent systems.
- dang 8y ago
  Please don't cross into incivility when commenting here, regardless of how right you are or feel you are. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

deleted 8y ago

[deleted]