Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reasons Django 1.3 will be awesome

blog.aawsolutions.com

Post reply on HN
Print view View original

11–15 of 15 posts

Re: Reasons Django 1.3 will be awesome

#11

Post by jacobian »

moe wrote: post #2

What is it with these mainstay frameworks that they never adopt the mature ORM on their respective platform but instead keep growing their own, less than half-baked alternative? We have this in django vs SQLAlchemy and Rails vs datamapper. The arguments that I've heard were mostly that the respective ORMs either weren't around when the framework started and/or that anyone "can just plug their preferred ORM in anyways…

I love SQLAlchemy - it's an amazing piece of software, and I use it often. So why wouldn't I argue for Django to switch?

* I love Django's ORM, too. It's far simpler, much easier to teach to new users, and results in code that "scans" better. It's only able to achieve that ease-of-use by sacrificing features -- a classic trade-off. Neither approach is more "right."

* SQLAlchemy didn't exist when we wrote Django. Yes, you've just dismissed that argument, but I can't. There are thousands -- probably tens of thousands -- of Django sites out there, and I'm not so quick to break backwards compatibility just for the new shiny.

* Finally, and most importantly, SQLAlchemy has some fundamentally different goals than Django's ORM. SQLAlchemy aims to provide an API to represent SQL in Python. Django aims to provide a persistance layer for objects. The difference between these philosophies is important: the use of a relational database is almost an implementation detail for Django, but it's SQLAlchemy's raison d'être. This isn't just academic: it means, for example, that Django's ORM will one day support non-relational databases (work here's already begun), but SQLAlchemy won't.

Re: Reasons Django 1.3 will be awesome

#13

Post by jacobian »

Destruct1 wrote: post #12

Before django implements new features it should rework some of the crappy old stuff: Auth is terrible, models and forms need to be more flexible. Also a lot of little things like forms myform.as_div are missing.

"Django" doesn't implement new features: people do. In this case, Ben Firshman led a group of about a dozen or more to get generic views refactored, and Carl Meyer took point on the long-requested on_delete work.

They had itches to scratch, and they scratched them.

I agree that auth's gotten long in the tooth, but not enough to be motivated to work on it. The fact that it's stayed unresolved for so long indicates perhaps that most contributors feel similarly. That means that it's going to stay as it is until someone steps up, like Ben or Carl did, and takes the lead in getting something done.

Alternatively, I'm available for consulting work and would happily take money to work on any problem you like. My rates are fairly reasonable.

Re: Reasons Django 1.3 will be awesome

#14

Post by zeemonkee »

Destruct1 wrote: post #12

Before django implements new features it should rework some of the crappy old stuff: Auth is terrible, models and forms need to be more flexible. Also a lot of little things like forms myform.as_div are missing.

The problem with auth is that it was designed before model inheritance was available, hence the crappy get_profile() hack.

A better solution (with hindsight) would be a base abstract UserBase model with a bunch of useful features (e.g. password encryption) extended by a default User model, plus a UserForeignKey field similar to the one in GAE. Therefore instead of this:

    class BlogPost(models.Model):
        author = models.ForeignKey(User)
you would have this:

    class BlogPost(models.Model):
        author = UserForeignKey()
The exact user class would be set in your settings, e.g. AUTH_USER_MODEL = "myapp.MyUser".

That would provide more interop between Django apps requiring some form of user authentication. Not sure what other implications that would have though.

Re: Reasons Django 1.3 will be awesome

#15

Post by baddox »

jacobian wrote: post #11
moe wrote: post #2

What is it with these mainstay frameworks that they never adopt the mature ORM on their respective platform but instead keep growing their own, less than half-baked alternative? We have this in django vs SQLAlchemy and Rails vs datamapper. The arguments that I've heard were mostly that the respective ORMs either weren't around when the framework started and/or that anyone "can just plug their preferred ORM in anyways…

I love SQLAlchemy - it's an amazing piece of software, and I use it often. So why wouldn't I argue for Django to switch? * I love Django's ORM, too. It's far simpler, much easier to teach to new users, and results in code that "scans" better. It's only able to achieve that ease-of-use by sacrificing features -- a classic trade-off. Neither approach is more "right." * SQLAlchemy didn't exist when we wrote Django. Yes,…

Your last point is by far the most important. It looks like one of the goals for Django 1.4 will be more separation between the ORM and relational databases. Alex Gaynor speaks at length about the innards of today's querysets and how he suggests it could be changed to make sense with NoSQL: http://nosql.mypopescu.com/post/904840384/django-and-nosql-d...
Post reply on HN