3 ms·
I use roughly this approach in Java, and I would argue that it makes the queries more available to the developer. Yes, they're in a different file. But it's an
by mumblemumble 6y ago
I use roughly this approach in Java, and I would argue that it makes the queries more available to the developer.
Yes, they're in a different file. But it's another file in the same codebase, and it's directly referenced by the code that's using it. This means it's not really any harder to track down than the code to a function that lives in a different file. It's really NBD.
And, in return for putting your SQL in .sql files, you get all sorts of nice things. Syntax highlighting for your SQL, for starters. And it's somewhere that autoformatters and linters and SQL unit testing tools and the like can get at easily. And you get SQL code that isn't being forced through whatever laundry wringer and or cheese grater is imposed by your language's string literal syntax. (This last one admittedly isn't such a problem in Python.)
This really isn't too far off from why your JavaScript code is generally happiest in .js files and your CSS is generally happiest in .css files, rather than making them all inline in your HTML.
- TedDoesntTalk 6y ago> This means it's not really any harder to track down Right. It’s not much different than a constants file.
- hoistbypetard 6y ago> And, in return for putting your SQL in .sql files, you get all sorts of nice things. Syntax highlighting for your SQL, for starters. Until recently I was looking for a good scheme to keep my sql in .sql files primarily for this reason. But some time in the past few releases, pycharm has started detecting SQL in strings, and if I add an instance of my DB as a data source to the project, it autocompletes table/column names, etc. I still see some appeal to putting my SQL in .sql files, but good IDE support has given me most of the benefit while keeping it in local strings, plus some help with prepared statements that would have required some added effort if I'd moved it to SQL files.
- mumblemumble 6y agoI definitely see an advantage there. But I still tend to prefer non-IDE solutions for things like code formatting and linting, because it means you have the option to configure them once in the build settings and forget about it. With IDE-based solutions, even if you can guarantee everyone is using the IDE (Which is already something I don't even want to guarantee. Friends don't make vim-loving friends use heavyweight IDEs. But I digress.), you still have to also remember to get everyone to set their IDE up properly, and verify that they did it. Otherwise you have a tendency for lint to collect unnoticed in the code for a while before it becomes obvious that someone missed a step in the onboarding checklist.
- bbsimonbb 6y agoWhat tools let you do this in Java? I'm looking at porting my QueryFirst extension to Java, and I couldn't find anything in the space. https://marketplace.visualstudio.com/items?itemName=bbsimonbb.QueryFirst&ssr=false#overview https://marketplace.visualstudio.com/items?itemName=bbsimonb...
- mumblemumble 6y agoI stick the *.sql files in the resources, and then created my own helper functions to grab them by filename. I was very new to Java at the time, so I had to spin my wheels on wrapping my head around how Java manages resources for an afternoon. It would have been done in no time at all if I had known about the Reflections library at the time.