5 ms·
This is a pretty natural thing to want, but is not actually usable in real world settings. If your SQL has to be computed at compile time, how do you implement
by Eridrus 8y ago
This is a pretty natural thing to want, but is not actually usable in real world settings.
If your SQL has to be computed at compile time, how do you implement any sort of search where you will have a variable number of ANDS & ORs?
- deleted 8y ago[deleted]
- gnud 8y agoYou could try to create some sort of SQL-builder API where each fragment must be static, and each fragment contains its own placeholders. Then you can use conditionals and loops to decide which fragments are included.
- pc86 8y agoOr you can just use runtime SQL injection prevention methods?
- coldtea 8y agoOr just have an employee carefully monitor user input manually, and have them propagate it to the backend with a delay. That is, sure, it's not like Rust takes the option to check for injection at runtime.
- jcelerier 8y agoWhy "just" ? It's incredibly more costly than having the injections being prevented at compile-time.
- ufo 8y agoI think the appeal of sql builder apis is that they make it much harder to shoot yourself in the foot. If your queries are strings you can use placeholder syntax to avoid injection but all there is nothing stopping you (or a junior dev) from writing something stupid like "and name ='" + username + "'". If queries are represented with a separate datatype then it is much harder to put unsanitized user input strings inside them.
- coldtea 8y ago>If your SQL has to be computed at compile time, how do you implement any sort of search where you will have a variable number of ANDS & ORs? It's not your SQL (e.g. whole query) that needs to be computed at compile time, but the proper escaping of placeholder parameters. So, the answer is: trivially.
- michaelmior 8y agoIn many cases that may be true, but not in the case of the parent comment you're responding to. The parent identifies a scenario where you have a faceted search functionality that generates conditions in the where clause of the query dynamically).
- coldtea 8y agoSo? What prevents those conditions to be generated as a number of SQL fragments that are statically checked for injection? What would be checked by Rust is the actual fitness of the fragments, not if your building them in a loop from pre-made WHERE, AND etc clauses + placeholders.
- michaelmior 8y agoDefinitely possible. Just more nuanced than the approach suggested in the article.
- OskarS 8y agoAs a non-webdev who only have a surface-level understanding of SQL: is that a thing people do regularly? Like, you literally append a bunch of strings together dynamically every request to construct queries?
- mooreds 8y agoIt is quite common to build up a query. You can and should still use parameters, but I have lost count of the times I have seen code like this: where = "1=1"; if (cond) { where += " and foo ='bar'"; } ...
- juliangoldsmith 8y agoI'd imagine it would depend entirely on the type of search you're trying to do. If you know all the possible ANDs and ORs beforehand, you could pass in flags to select which ones to use. That would also mean you could prepare queries ahead of time, and not need to compile them every time you run them. I don't think there would be many situations where you wouldn't know what possible filters you could have at compile time, and in such a situation I'd question whether there was a better way to implement what I was trying to do.