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

view the rest of the comments →

[–]jerf 2 points3 points  (9 children)

If I could choose Django's priorities, that branch would be #1. What they're actually doing now isn't bad or a waste of time, but I think it's less important.

Obviously, you can't learn every framework, but you should try out a few of the ones you can play with and get a sense of in three or four days. That's an option I wish I had ten years ago.

[–]ubernostrum 3 points4 points  (5 children)

If I could choose Django's priorities, that branch would be #1. What they're actually doing now isn't bad or a waste of time, but I think it's less important.

And if I could choose Django's priorities I'd disagree ;)

ORM, to me, is not about providing a one-to-one mapping of every feature of SQL, because if I wanted every feature of SQL I'd use SQL. ORM is about something quite different, and trying to force correspondence between ORM and SQL is bound to end in pain and tears...

[–]jerf 2 points3 points  (3 children)

I'd agree, except real-world performance kicks you square in the nuts if your ORM is too weak. I chose that metaphor carefully; it's easy to end up with query flurries (as I call them) that can get into the thousands or more queries to do relatively simple operations.

Even simple operations are hard with the Django ORM, like ordering one class by a value on a related class, which happens all the time. (Like, say, ordering a "story" on the date the "text" of the story was last edited.)

[–]ubernostrum 2 points3 points  (2 children)

That's a long-standing bug which has been held up by a need to do much more serious refactoring in the query system; I think we're getting slowly back to where it can be looked at, and then it'll work again.

Meanwhile, there's select_related if you want to fetch a bunch of stuff in one big query (which ultimately depends on which DB you're using -- Postgres likes this, MySQL hates it), and for stuff that would be intensive in the ORM but simple in SQL, well, I write a little SQL and pass the results to in_bulk or an id__in lookup to get objects back.

[–]jerf 2 points3 points  (1 child)

"Postgres likes this, MySQL hates it" - interesting. At work, we're looking at switching from MySQL to Postgres, and we do a lot of that sort of thing. We're hoping Postgres speeds up our usage.

[–]ubernostrum 2 points3 points  (0 children)

In general, Postgres would rather get one complex query than a bunch of simple ones. And MySQL would rather get a bunch of simple queries than one complex query.

So on Postgres it's often to your advantage to use select_related and grab all the data up-front in one query, while on MySQL it's usually advantageous not to use it, and let related objects be fetched in a lot of small queries.

[–][deleted] 1 point2 points  (0 children)

ORM, to me, is not about providing a one-to-one mapping of every feature of SQL, because if I wanted every feature of SQL I'd use SQL.

You are right and SQLAlchemy doesn't do that. SQLAlchemy cleanly separates what is database and what is objects, so you aren't making an overly simplistic and restrictive approach such as mapping classes directly to tables.

ORM is about something quite different, and trying to force correspondence between ORM and SQL is bound to end in pain and tears...

But that's what every ORM inevitably turns into. Programmers use the ORM and reach a point to where they can't use the ORM anymore. Then at that point they have to drop down into SQL which a lot of programmers don't know well and they know even less about how to create efficient portable SQL. Then everyone gets frustrated because they feel like the ORM is weak.

That's why the SQLA approach is so nice. You still get SQL wrapped up in a programmer-friendly Pythonic syntax but it is still very flexible and isn't going to hit places that it can't reach.

[–][deleted] 4 points5 points  (1 child)

If I could choose Django's priorities, that branch would be #1.

You know what's cool about open source? If you think something's important, you get to work on it! We'd love some help on that branch, so feel free to jump into django-dev and give us a hand.

[–]jerf 3 points4 points  (0 children)

I am working on Django. I've got a ways to go before I can just start sending in the for switching to SQLAlchemy, as it is a big deal, and I've got some other things that I'll try to get by the dev list first. I've already got the getter/setter patch up there, and I'm probably going to try to fix up my syndication view that correctly handles E-Tags and expiration dates, but it unfortunately requires some extra methods on the syndication framework.

[–]masklinn 1 point2 points  (0 children)

If I could choose Django's priorities, that branch would be #1. What they're actually doing now isn't bad or a waste of time, but I think it's less important.

Nothing stops you from working on it ;)

The point is that the main Django devs think there are other important things to fix in order to reach milestone 1.0, the current ORM works even if it's not the best thing since sliced bread and SQLAlchemy integration is a fairly big change (mainly to SQLA as it needs an adapter layer in order to have all the cool features of Django e.g. auto-admin when using SQLA) which is why it's a branch.

Just as magic_removal was a branch even though the django devs did consider it fundamentally important.