[benselme]

Well, ORMs are useless if you're of the opinion that string interpolation and concatenation are a good way of composing logical units. Many of us prefer a proper API for doing that, and good ORMs like SQLAlchemy provide us with one.

[datashaman]

PDO in PHP has parameter binding and a way of loading a row from a resultset into a class. Safe, simple, and flexible. That's good enough for me. YMMV.

[mantrax5]

"foo > 123 or foo IS NULL and bar < 12"

Now write this in SQLAlchemy without strings, without concatenation, and let's see which provides you with more clarity.

[benselme]

(FooBar.foo > 123) | (FooBar.foo == None) & (FooBar.bar < 12)

No strings, and I get an actual expression object instance that I can, for example, store in a variable and reuse in any number of queries.

[coleifer]

Yes! Plus if you have a syntax error Python will catch it for you. Peewee works the same way.

[anton_gogolev]

LINQ. Composable queries rock.

[personZ]

LINQ is a black-box that is often disastrous for application performance. The more LINQ in a project, the more likely the project is headed to failure.

[anton_gogolev]

First of all, are you aware that LINQ is not only about database access?

Second, how is it a black box? It is the particular query provider implementation that is a black box.

Third, there's absolutely no correlation between the amount of LINQ and success of a project.

[personZ]

are you aware that LINQ is not only about database access

Yes, I am aware. How is this relevant at all to the context of this thread?

The rest of your comment: You are simply wrong. A heavy use of LINQ is one of the surest sign that one needs to run from a project. It is almost always used and embraced by people who have no concept of the consequences, imagining that the conciseness of LINQ = programming goodness, when the opposite is generally true.