7 ms·

You missed the last sentence of the comment. Even with custom query, using escape hatch bring a lot to the table because you benefit from the ORM core handling

You missed the last sentence of the comment. Even with custom query, using escape hatch bring a lot to the table because you benefit from the ORM core handling system for configuration, serialization, pooling, etc. Not to mention some core (like sqla core) in fact include a functional query language that is capable of representing low level sql in any form. In which case you benefit even more, and you can do your report perfectly.

doctor_eval 4y ago
So now you need to know two languages to access the database. :-/
- Foobar8568 4y ago
  But these are actually for different purposes and requirements. KISS and DRY are respected.
- BiteCode_dev 4y ago
  Unless you access the database only and don't have the reports accessed through an end-user application, you usually have some language involved to call your SQL queries, normalize input, abstract them away, etc. You do have to learn an additional API, but as a programmer, that's something I have to do every day anyway.
- ludston 4y ago
  At the very least you should know SQL. The purpose of having a query dsl in some other language isn't to avoid understanding sql, it's because sql isn't easily composable.
  - ttfkam 4y ago
    CTEs. Views. Set-returning functions. "SQL isn't easily composable" is a pernicious lie. Does it compose like your favorite functional language? No. SQL is not nor has ever been a functional or object-oriented or generic or procedural language. It's a fourth-generation declarative set-oriented language, so the composability is going to be based on sets. Period. Until you think of SQL as a set-oriented declarative language, you will be perpetually trying to push water uphill, ORM or no.
    - ludston 4y ago
      It's not a pernicious lie at all. You can't just say, it's composable so long as you only compose with the special mentality that you consider to be blessed. Also the fact that SQL acts on sets is completely irrelevant to the syntax being composable or not. JSON is programmatically composable. XML is programmatically composable. S-expressions are programmatically composable. Most programming language syntax's are not. If you build a UI or reporting mechanism that wraps around an SQL engine and has multiple configuration options that combine to determine the SQL expression that should be used, the fact of the matter is that you will either abstract the combination of the configuration into a DSL that then gets converted to SQL, or you will have a mess of string concatenation that isn't type-safe and isn't verifiably correct until runtime. Show me the code you'd write to generate an SQL expression with ten optional filters, where each filter is comparing a different column to a set, and if the set is empty the filter should be ignored. I'll show you a DSL that does the same thing, is readable and statically verifiable, and ensures that if anybody else ever writes a similar query guarantee's that parameters will be the same so that the execution plan can be cached.
      - ttfkam 4y ago
        S-Expressions are not a set-based construct. Neither is JSON nor XML. Those are all document-oriented and/or hierarchical tree structures. I did not "bless" SQL as a set-based language. It's literally a 4th generation, declarative DSL for set theory. That was its design goal. That's the lens through which every change to the language and the engines that implement it are discussed and adopted. If I said LISP sucked at object-oriented programming and OO design patterns, how would you react? How about if they said LISP shouldn't be solely through the lens of functional programming just because that's your "blessed mentality" for it. I don't even know how to respond to that assertion. "It's not even wrong."
        ludston 4y ago
        I would probably say that you are miss-understanding the difference between syntax and the evaluator that evaluates that syntax. All three of these expressions contain the same data: (select (col1 col2) (table1) (= col1 "foo")) "select col1 col2 from table1 where col1 = 'foo'" <select><columns><column>col1</column><column>col2</column></columns><tables><table>table1</table></tables><filters><equalityfilter><column>col1</column><value>foo</value></equalityfilter></filters></select> All three of these are "4th generation, declarative DSLs for set theory" as you like to brandish around. > If I said LISP sucked at object-oriented programming and OO design patterns, how would you react? How about if they said LISP shouldn't be solely through the lens of functional programming just because that's your "blessed mentality" for it. S-Expressions are just a syntax. It's quite normal to see Lisps that are functional, declarative, object-oriented or procedural. The only thing that differentiates Lisps from other programming language is the simplicity of the syntax enabling meta-programming, which is specifically the problem with SQL syntax and it's composability.
ludston 4y ago
> You missed the last sentence of the comment I didn't, and I agree with the comment. I'm elaborating upon it.

doctor_eval 4y ago

So now you need to know two languages to access the database. :-/

Foobar8568 4y ago
But these are actually for different purposes and requirements. KISS and DRY are respected.
BiteCode_dev 4y ago
Unless you access the database only and don't have the reports accessed through an end-user application, you usually have some language involved to call your SQL queries, normalize input, abstract them away, etc. You do have to learn an additional API, but as a programmer, that's something I have to do every day anyway.
ludston 4y ago
At the very least you should know SQL. The purpose of having a query dsl in some other language isn't to avoid understanding sql, it's because sql isn't easily composable.
- ttfkam 4y ago
  CTEs. Views. Set-returning functions. "SQL isn't easily composable" is a pernicious lie. Does it compose like your favorite functional language? No. SQL is not nor has ever been a functional or object-oriented or generic or procedural language. It's a fourth-generation declarative set-oriented language, so the composability is going to be based on sets. Period. Until you think of SQL as a set-oriented declarative language, you will be perpetually trying to push water uphill, ORM or no.
  - ludston 4y ago
    It's not a pernicious lie at all. You can't just say, it's composable so long as you only compose with the special mentality that you consider to be blessed. Also the fact that SQL acts on sets is completely irrelevant to the syntax being composable or not. JSON is programmatically composable. XML is programmatically composable. S-expressions are programmatically composable. Most programming language syntax's are not. If you build a UI or reporting mechanism that wraps around an SQL engine and has multiple configuration options that combine to determine the SQL expression that should be used, the fact of the matter is that you will either abstract the combination of the configuration into a DSL that then gets converted to SQL, or you will have a mess of string concatenation that isn't type-safe and isn't verifiably correct until runtime. Show me the code you'd write to generate an SQL expression with ten optional filters, where each filter is comparing a different column to a set, and if the set is empty the filter should be ignored. I'll show you a DSL that does the same thing, is readable and statically verifiable, and ensures that if anybody else ever writes a similar query guarantee's that parameters will be the same so that the execution plan can be cached.
    - ttfkam 4y ago
      S-Expressions are not a set-based construct. Neither is JSON nor XML. Those are all document-oriented and/or hierarchical tree structures. I did not "bless" SQL as a set-based language. It's literally a 4th generation, declarative DSL for set theory. That was its design goal. That's the lens through which every change to the language and the engines that implement it are discussed and adopted. If I said LISP sucked at object-oriented programming and OO design patterns, how would you react? How about if they said LISP shouldn't be solely through the lens of functional programming just because that's your "blessed mentality" for it. I don't even know how to respond to that assertion. "It's not even wrong."
      - ludston 4y ago
        I would probably say that you are miss-understanding the difference between syntax and the evaluator that evaluates that syntax. All three of these expressions contain the same data: (select (col1 col2) (table1) (= col1 "foo")) "select col1 col2 from table1 where col1 = 'foo'" <select><columns><column>col1</column><column>col2</column></columns><tables><table>table1</table></tables><filters><equalityfilter><column>col1</column><value>foo</value></equalityfilter></filters></select> All three of these are "4th generation, declarative DSLs for set theory" as you like to brandish around. > If I said LISP sucked at object-oriented programming and OO design patterns, how would you react? How about if they said LISP shouldn't be solely through the lens of functional programming just because that's your "blessed mentality" for it. S-Expressions are just a syntax. It's quite normal to see Lisps that are functional, declarative, object-oriented or procedural. The only thing that differentiates Lisps from other programming language is the simplicity of the syntax enabling meta-programming, which is specifically the problem with SQL syntax and it's composability.

ludston 4y ago

> You missed the last sentence of the comment I didn't, and I agree with the comment. I'm elaborating upon it.