4 ms·

Just a UI issue. Compilers will warn you if you do stupid common mistakes. Not all mistakes, but many of the stupid common ones. If you make stupid common mist

by Arnt 8y ago

Just a UI issue. Compilers will warn you if you do stupid common mistakes. Not all mistakes, but many of the stupid common ones. If you make stupid common mistakes with an ORM, why doesn't the ORM warn you?

olavk 8y ago
They require rather sophisticated analysis to detect. A compiler will detect trivial errors, but will not flag if you are using an O(n) algorithm when an O(1) could be used. Not yet, anyway.
- Arnt 8y ago
  I read the paper. A third, maybe half of the stuff the ORMs didn't detect looks simple to detect. (Greybeards may remember how perl's -W switch switch suddenly detected a frightful amount of performance problems using mostly simple tests. Almost 20 years ago now.)
  - olavk 8y ago
    Maybe you are on to something. All the major ORM's are open source (AFAIK) so if you made a write-up of the common issues and how you suggest they could be detected by the ORM, I think it would be very well received.
    - tonyarkles 8y ago
      The authors of the paper, if I’m remembering from reading it earlier today, built a static analyzer to help find these types of problems! Some of the work has already been done!
    - vidarh 8y ago
      I'd think you could do warnings on this simply by processing a log of the queries, looking for query patterns that match common poor code patterns. E.g. SELECT id FROM table [some conditions] followed by a number of SELECT * FROM table WHERE id = ... is one example of a anti-pattern that suggests that someone is doing an overly simplistic query followed by a loop. Similar with signs of triggering loading of related objects instead of a JOIN. Doing it on the emitted SQL would also make it quite easy to make it reasonably ORM agnostic - it doesn't need to be perfect, after all, so doing relatively crude pattern matching ought to be able to find at least the more basic problems.

by Arnt 8y ago

olavk 8y ago

They require rather sophisticated analysis to detect. A compiler will detect trivial errors, but will not flag if you are using an O(n) algorithm when an O(1) could be used. Not yet, anyway.

Arnt 8y ago
I read the paper. A third, maybe half of the stuff the ORMs didn't detect looks simple to detect. (Greybeards may remember how perl's -W switch switch suddenly detected a frightful amount of performance problems using mostly simple tests. Almost 20 years ago now.)
- olavk 8y ago
  Maybe you are on to something. All the major ORM's are open source (AFAIK) so if you made a write-up of the common issues and how you suggest they could be detected by the ORM, I think it would be very well received.
  - tonyarkles 8y ago
    The authors of the paper, if I’m remembering from reading it earlier today, built a static analyzer to help find these types of problems! Some of the work has already been done!
  - vidarh 8y ago
    I'd think you could do warnings on this simply by processing a log of the queries, looking for query patterns that match common poor code patterns. E.g. SELECT id FROM table [some conditions] followed by a number of SELECT * FROM table WHERE id = ... is one example of a anti-pattern that suggests that someone is doing an overly simplistic query followed by a loop. Similar with signs of triggering loading of related objects instead of a JOIN. Doing it on the emitted SQL would also make it quite easy to make it reasonably ORM agnostic - it doesn't need to be perfect, after all, so doing relatively crude pattern matching ought to be able to find at least the more basic problems.