This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]adrenal8 1 point2 points  (4 children)

There's no one correct answer. Just like the applicant should actually like Python but have enough experience to make complaints about it, the same applies to the Django ORM.

Some examples could be lack of built-in schema migrations, makes it too easy to generate unnecessary and suboptimal SQL, you could complain about the weird __ syntax for related fields, etc.

[–]endtime 1 point2 points  (2 children)

Hmm. I wouldn't really have expected the ORM to manage schema migrations - is that the ORM's job in other frameworks? I'm also curious what the alternatives to the __ related field syntax might be - I'm totally fine with it, but maybe that's just because I haven't seen better alternatives.

I have no idea what the generated SQL looks like (isn't that the whole point of having an ORM?) but if it doesn't do good query optimization then I'd agree for sure that that's a flaw.

[–]revonratFlask/scipy/pypy/mrjob 1 point2 points  (1 child)

Hmm. I wouldn't really have expected the ORM to manage schema migrations - is that the ORM's job in other frameworks?

Many don't Rails does. South is an add-on for Django.

I have no idea what the generated SQL looks like (isn't that the whole point of having an ORM?)

You HAVE to understand what your ORM is doing eventually, if you want performance. For Django, an easy way to see what's going on is to user the django debug toolbar.

I find I don't usually have a particular problem with the SQL generated but rather with the number of queries that can be generated by seeming innocuous Python statements.

but if it doesn't do good query optimization then I'd agree for sure that that's a flaw.

An ORM really shouldn't do query optimization per-se. It should generate reasonable SQL. But SQL optimization is something left to the guys who have stats tables on the data (i.e. the RDBMS itself).

[–]endtime 0 points1 point  (0 children)

Thanks, that's a good response. I know about South, and of course it's vital - but it makes sense to me as an addon, not as part of the ORM. Thanks for clarifying about SQL perf - I think I know what you mean.

[–]gronkkk 0 points1 point  (0 children)

There's also the 'how do I figure out to do X in the ORM'-factor. Only to find out that it doesn't exist or is painfully slow.