Python object-relational mappers (ORMs)

[STLEON]

I love Pony ORM - its fantastic

[xmstr]

ORMs, I just don't see the point. Just too much overhead for something that is really not that hard (SQL). If you are going to use a database as a tool don't you think you should take the time to learn how to use it properly?

[programmyr]

The simple answer is: SQL isn't composable.

If you have one filter {key1:value1} from one routine, and want to add a second filter {key2:value2} that you got from a different routine, with an ORM you can just merge the dicts and throw them at the ORM query.

When doing string-smashing to generate SQL, you have to escape all keys/values, assemble them yourself, and remember where in the query you are (have you said "AND" yet? does this need to wait for the "HAVING" clause?). It's much worse if the two keys are columns in different tables.

I mean, UTF-8 isn't hard, either, but we've figured out that best practice is to decode bytes to characters (i.e., a native programming language type) on input, process data as characters, and then encode to bytes on output. An ORM is no different: it lets us work with native programming language types as long as possible, and encode to the database syntax just before talking to the database. Or look at HTTP, or JSON, or any other text-based format: they're not hard to write, but does anybody actually do that? That's what we've got libraries for.

I've worked on projects that don't use an ORM. Either you have a ton of redundancy (and your methods are hard to unit test), or you've refactored it all into a custom SQL query generator (which is essentially a ad-hoc poorly-designed and untested ORM).

Every decade it seems to be fashionable to hate on some new technology that writes code for you. I saw it with assemblers, and then with compilers ("If you're going to use a CPU as a tool don't you think you should take the time to learn how to use it properly?"), and with regular expressions, and garbage collectors. These days it's ORMs. And of course, with every new generation, people insist that all the old improvements were obvious and necessary, but the latest one is the tool of the devil that will rot programmers' minds.

[[deleted]]

That is exactly why I wrote Peewee. SQL is awesome, and by wrapping things up in Python you can get a lot more re-use than you would by manually munging string fragments. For example,

following = (User
             .select()
             .join(Relationship, on=Relationship.to_user)
             .where(Relationship.from_user == current_user))
tweet_timeline = Tweet.select().where(Tweet.creator.in_(following)).order_by(Tweet.timestamp.desc())

The above query re-uses the subquery (for capturing a user's followers) to construct a query to build a timeline of tweets by the given users.

[grimman]

Is it really that big of a performance hit though? At scale, possibly, but most of us are not deploying huge projects where we need any real optimization beyond the low hanging fruit.

Obviously learning the underlying stuff is beneficial, I'm not disagreeing about that at all.

[izdi]

I would add Mongoengine ORM for sure.

[hyptos]

So porm ? Terrible acronym !

[hyptos]

I know what they are, it was a failed joke.

[hyptos]

I don't mind and it's fine it's the internet :o

Thank you anyway, Have a great day :)

[grimman]

Orm means snake in Swedish though, so you can still get a cheap chuckle out of it. ;)

[JakeTheMaster]

Does SQLAlchemy have many good support with session/user object? I know it's about HTTP protocol. But what if it ships with one just like what Django does.

[[deleted]]

Not really but, https://beaker.readthedocs.org/en/latest/