This is the problem with not using an ORM. If you cut it out and move everything to parameterized SQL queries the SLOC explodes which massively inhibits readability as well as introducing bugs.
If your issue with ORMs is just that you're familiar with SQL and you don't like how ORMs look then I think the issue is just about becoming more familiar with a decent ORM.
My experience has been the opposite: that raw SQL queries end up much shorter (and consequently more readable) than the equivalent ORM code. The exception to that is INSERT/UPDATE queries, where I do tend to use some kind of ORM/query builder. I have used both, and I prefer raw SQL for anything beyond very simple queries.
IMO:
.where('column_a', '=', 'value1')
.and(q => q.isNull('column_b').orWhere('column_b', '=', 'value2')))
WHERE
column_a = 'value1'
AND (column_b IS NULL OR column_b = 'value2')And obviously you can use whatever indentations you like.
- No keyword arguments
- No operator overloading (so you can't override | to get the nice "or" syntax)
In JS, theoretically you could design an API like
.where({column_a: 1}, Q(column_b__isnull=True).or({column_b: 2}))
Which really isn't bad IMO
filter( Q(column_b__isnull=True)|Q(column_b='value2'),
column_a='value1',
)
.filter(Q(column_a='value1'), Q(column_b__isnull=True)|Q(column_b='value2')) .filter(Q(column_a='value1') & (Q(column_b__isnull=True) | Q(column_b='value2'))) Dog.objects.filter(owner__city__name = 'New York')