Right, there's only like a million of these already in existence in every language and I have yet to find one that is comprehensive enough that I don't just fall back to regular sql queries sooner or later.
And if you think about it, any library that was powerful enough for me to not write SQL anymore would basically have to rewrite the complete SQL spec using awkward hacks in a language that is totally unsuited for it.
And if you're writing an application of any complexity or size using an SQL database you need the full capacities of SQL. There are a lot of little features or quirks of SQL that these languges seem to overlook that you need to make your app perform.
Now I usually just write a couple functions like this:
query("SELECT one, two FROM mytable",
["WHERE weight > %f AND name = '%s'", weight, name]);
That gives me SQL-injection protection, lets me save subqueries as strings and re-use them, and caching to if I need it.
And as a plus, I don't have continuously look up/relearn each little feature of SQL in this little language, or if I write it this way is it actually going to compile into the SQL I want? It's pretty much inevitable that you're going to need to know/control the SQL that's being written sooner or later (usually sooner), so save yourself the extra headache and just go SQL from the start.
I know we're talking about python, but personally I advise against raw SQL because there is no type protection of any kind. In, e.g. C# I can use Linq to ensure I build a query that type checks and makes sense, even across joins.
It seems from others' replies that it's not optional. It certainly isn't in English. I put it in not to correct but to explain my interpretation of what was written to better frame my question.
And if you think about it, any library that was powerful enough for me to not write SQL anymore would basically have to rewrite the complete SQL spec using awkward hacks in a language that is totally unsuited for it.
And if you're writing an application of any complexity or size using an SQL database you need the full capacities of SQL. There are a lot of little features or quirks of SQL that these languges seem to overlook that you need to make your app perform.
Now I usually just write a couple functions like this:
That gives me SQL-injection protection, lets me save subqueries as strings and re-use them, and caching to if I need it.And as a plus, I don't have continuously look up/relearn each little feature of SQL in this little language, or if I write it this way is it actually going to compile into the SQL I want? It's pretty much inevitable that you're going to need to know/control the SQL that's being written sooner or later (usually sooner), so save yourself the extra headache and just go SQL from the start.