5 ms·

Nested queries? Joins? Stored procedures? Views? This is literally everything SQL was made for. Modify a query? Literally just code. Like what do you people t

by lugg 8y ago

Nested queries? Joins? Stored procedures? Views? This is literally everything SQL was made for. Modify a query? Literally just code. Like what do you people think SQL is? Select * from table?

platz 8y ago
We are talking about programmatically constructing a query at runtime by stictching together bits of sql, in a way that which bits of sql you use are actually dependent on the runtime state, and in a way that is type-safe. You could do something similar with either dynamic queries in a stored procedure, but without a DSL those dynamic queries are brittle, and the runtime composition using them is hard and error prone.
- 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
- karmakaze 8y ago
  The metaprogrammability using an ORM has never been wroth the loss of expressiveness in my experience. If I needed it, I'd probably not be using the procedural language the the ORM uses.

by lugg 8y ago

Nested queries? Joins? Stored procedures? Views? This is literally everything SQL was made for. Modify a query? Literally just code. Like what do you people think SQL is? Select * from table?

platz 8y ago

We are talking about programmatically constructing a query at runtime by stictching together bits of sql, in a way that which bits of sql you use are actually dependent on the runtime state, and in a way that is type-safe. You could do something similar with either dynamic queries in a stored procedure, but without a DSL those dynamic queries are brittle, and the runtime composition using them is hard and error prone.

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
karmakaze 8y ago
The metaprogrammability using an ORM has never been wroth the loss of expressiveness in my experience. If I needed it, I'd probably not be using the procedural language the the ORM uses.