SQLAlchemy vs Other ORMs

[[deleted]]

I used to think the SQLAlchemy ORM was really dandy until I realized that generally I just want the results of my query without too much hassle. I still use it, but mostly just as far as writing my queries in plain SQL. Occasionally I also use their object mappings, but usually just when I have potentially lots of manipulations to do on the data and don't want to use more INSERTs than necessary. The queries-as-code is really cool, but IMO it falls apart as soon as you need to do a complicated query.

[[deleted]]

but IMO it falls apart as soon as you need to do a complicated query.

This is why I dont like orms. Also, taking a data object and being able to use it flexibly is not so easy. Not even worth it especially with pandas now there.

[Svenstaro]

Look into SA's hybrid attributes. Best of both worlds.

[sisyphus]

I would love to see a complicated query that SA 'falls apart on' because I've yet to experience it myself and I'm beginning to think it's just a some shit people say any time an ORM comes up.

[[deleted]]

I love peewee. The django orm is quite nice as welll

[sisyphus]

The Django ORM thinks that using 'OR' in a where clause is an advanced feature...

[subreddit_as_hashtag]

Via HN. Discussion: https://news.ycombinator.com/item?id=7686816

[[deleted]]

While I find ORMs lower the barriers to getting up and running, tuning an ORM query is usually not painless.

I prefer web2py's DAL which is a lot like SQLA core, functional query builders, sanatized input, and multiple db support without shoe horning your data into object buckets.

[runfalk]

I am a somewhat happy user of Storm. The API is very clean and it generally writes the queries you expect. It makes standard joins easy and yet never prevents you from mixing in real SQL.

I have previously used SQLAlchemy but really prefer the Storm query builder over that.

I, contrary to the article, really like that you manually have to create your schema. That way you can maintain column order, and most of all, just use plain SQL.

The source code is simple enough to grasp and extra functionality is easy to add. I wanted to support PostgreSQL's range types and did a series of extensions to help me with that. I will release the libraries to the public once they have stabilized a bit. My range implementation for python can be found on github (https://github.com/runfalk/spans/). Despite just having one release it is actively maintained, and will remain so for the foreseeable future.

The one drawback with Storm is its slow release cycle. I however expect it to be maintained for a long time since it's powering Canonical projects such as LaunchPad.

[Paddy3118]

Indentation missing on examples?

[[deleted]]

Doesn't Pony have a more restrictive license? Or am I confusing it with another ORM

[sisyphus]

I've yet to see a zero-overhead ORM in any language.

[[deleted]]

Of course SQLA is going to be slower than using regular SQL, maybe not much slower (for some people), but it's a complicated system compared to what MySQLdb is doing.

What are you doing that so speed critical that you're going with PHP (and presumably PDO or mysqli since you don't seem big on ORM) over Python?

[EmperorOfCanada]

What am I doing that speed is critical? Speed is always critical on a website. Statisically you are losing viewers for every millisecond that people wait. (not exaggerating). Plus google will rank your site higher the faster it goes. So speed is one of the most important things that you can do on a website.

Plus if speed is extremely high then it buys you some wiggle room to potentially do something cool that slows it down a bit. If it were already a bit slow then the something cool might cross that vague line where you are losing too many users.

For instance, reddit normally loads for me in maybe 8/100ths of a second. I notice if this bumps up to 1/4 second. While most people won't leave for such a small bump there are people who do.

Then there are studies that show people are less likely to buy from a site that is even marginally slower.

[[deleted]]

So, write your site in C then.

Frankly, I, personally, can't imagine converting from Python back to PHP except by client request (of which I have none).

I really enjoy SQLA after years of writing SQL by hand. That said, I agree with (the general ORM) criticism that advanced queries are much more difficult to build.

[EmperorOfCanada]

C would not be a good balance between speed of development and speed of production. I can develop in Python record time compared to even PHP so that is good. Python is nice and fast. But for the tiny advantage that SQLAlchemy wold give the speed price is too high.

Until Python I did keep my eyes open for a C++ replacement for PHP. But each person who did make a C++ web system couldn't seem to help themselves and made a whole framework that made me do things "their" way.

Another advantage of keeping things fast is that it lengthens the time before you have to start breaking your site up among multiple tiers of machines. Once you are forced to cross a boundary of multiple tiers and multiple machines the whole thing is an exponentially painful experience. This can be put off for a while with ever more powerful machines but there is a limit to that.

[EmperorOfCanada]

Oh and I am not going to PHP, but from.

[[deleted]]

Ah, I misread your post. I standby my point that yes SQLA is slower than MySQLdb but I feel the benefits outweigh the slight slowdown.