Comment by somat
11 hours ago
I am in that club. As someone who quite enjoys writing sql but does not like the big sql strings intermingled in the rest of the code I even wrote a clever little python library that loads the queries from files as a function call, that is, you have a file with a pure sql query with parameterized variables and you call it like "for row in sql.video_search(title_like='bridge', date_after='1964-1-1', date_before='1975-1-1')" Nowhere near an orm, everything just produces a result set.
I am sure there are many projects like it, I suspect it is like static site generators and notekeeping apps, easy enough that everybody just makes their own. But this one is mine, and I have grown quite fond of it and use it in all my scripts. It is a little more magic than I am normally comfortable with. dynamic function generation is a bit of a black art, but having each query as it's own callable unit is super handy.
and i think this is somewhere in the ballpark of a p good approach, treat it as a dataset that has some predefined queries to get what's needed if you're OCD about seeing it in the code
sql is an interface query way to talk to databases, and treating things as datasets where their initialization query lives in a certain spot that flows into something generic/typed or whatever so that it can be wrangled elsewhere in the code with its own bespoke guarantees and handling behaviors is fine i think
i think i just don't think seeing sql in code or near code is a bad thing at all, to me it just means this code talks to a database and its using the database dialect/language to query the data. maybe people see string replacements over the query to apply variables or whatever as a bad thing i dunno, I think it's a relatively simple way to look directly at how a query might be dynamically adjusted on the fly. i dont have to like step through the lineage of methods and whatever other abstractions to formulate _how_ it put a query together. it's definitely annoying that there's some wild west feel to having so many dialects of sql, but it's a hard bet to make that you're going to make a better sql in 11 lines of code. SQL looks different than code because it is different, it's entire function is different, different paradigms are at play it's specifically purposed for querying and it excels at that on every front.