3 ms·

Right, how often do you actually need to do this? In my experience query building to this degree is usually a sign of over optimising for code reuse where it i

by lugg 8y ago

Right, how often do you actually need to do this? In my experience query building to this degree is usually a sign of over optimising for code reuse where it isn't really needed. The times it does make sense, it's usually a search problem that is better solved by something like elastic search. That isn't always feasible so what you end up with is a naive approach and just build the damn string. Or if it's needed you decompose it into the parts that are needed elsewhere table_headers() is usually all you need to stay DRY. It's not as pretty as an ORM, it shouldn't be used for every little query "because you might need it in the future". But the cases it is needed are rare, so does it really matter? Like you've got to adjust your frame of reference. Your database schema is static, it's not going to completely change out from under you at runtime, it's just a non problem.

flukus 8y ago
>Right, how often do you actually need to do this? In my experience query building to this degree is usually a sign of over optimising for code reuse where it isn't really needed. I need to very often and it's rarely about code reuse. You requirements like "on the client list screen we want to be able to search by client id or client name and we want to be able to sort by last login time or name"? What about writing an API, that's 90% handling things like this. And then there's the other cases ORM's solve, like representing data as something more than a 2D table.
- lugg 8y ago
  That problem is a query building problem you probably want to look into graphql. ORMs sometimes come with query builders that help things but in my experience it's not worth having to clusterbomb my codebase for it.
  - platz 8y ago
    Implementing graphql, which you can only apply in a limited number of client-server scenarios, to solve a relatively trivial problem, sounds like the clusterbomb or a good 2,000 lb mk-84 general purpose bomb to me e.g. graphql is not a panacea

by lugg 8y ago

flukus 8y ago

>Right, how often do you actually need to do this? In my experience query building to this degree is usually a sign of over optimising for code reuse where it isn't really needed. I need to very often and it's rarely about code reuse. You requirements like "on the client list screen we want to be able to search by client id or client name and we want to be able to sort by last login time or name"? What about writing an API, that's 90% handling things like this. And then there's the other cases ORM's solve, like representing data as something more than a 2D table.

lugg 8y ago
That problem is a query building problem you probably want to look into graphql. ORMs sometimes come with query builders that help things but in my experience it's not worth having to clusterbomb my codebase for it.
- platz 8y ago
  Implementing graphql, which you can only apply in a limited number of client-server scenarios, to solve a relatively trivial problem, sounds like the clusterbomb or a good 2,000 lb mk-84 general purpose bomb to me e.g. graphql is not a panacea