Django 1.1 is out

http://docs.djangoproject.com/en/dev/releases/1.1/

by mtrichardson • 17 years ago

123 13 17 years ago

docs.djangoproject.com

mtrichardson• 17 years ago

Download URL: http://www.djangoproject.com/download/1.1/tarball/

shabda• 17 years ago

And the weblog entry. http://www.djangoproject.com/weblog/2009/jul/29/1-point-1/

forsaken• 17 years ago

    And that's the way it is.

Gotta love the journalism history of the framework coming through :)

jokull• 17 years ago

Model validation and multi-db will hopefully be in the 1.2 release. At which point I wonder how the Django ORM stacks up against SQLAlchemy.

smithjchris3• 17 years ago

Model validation should have been there from day one. Well thats what us Domain-Driven-Design advocates push.

SQLAlchemy is way more powerful and flexible. Scan the SQLAlchemy documentation for examples. Particularly storing nested structures and support for inheritance (which is broken in Django).

SQLAlchemy is basically Hibernate in Python.

ubernostrum3• 17 years ago

  support for inheritance (which is broken in Django)

Django's ORM supports:

* Multi-table inheritance (just subclass and do stuff).

* Abstract parent classes (which get you most use cases for single-table inheritance).

* Pure-Python inheritance (via proxy models).

So I'm not sure how that's "broken".

But it's also worth noting that Django's ORM and SQLAlchemy approach the problem of ORM from opposite directions: Django starts at the object layer and works back to SQL, while SQLAlchemy starts at the SQL layer and works back to objects. Both have advantages and disadvantages, and both have their use cases.

chairface• 17 years ago

The big thing for me that's missing from Django's ORM is being able to map a model to an arbitrary select. It offers so much flexibility.

bretthoerner• 17 years ago

Can you give an example of what you mean?

ubernostrum3• 17 years ago

As I noted in my other reply, the two projects take different approaches, which are suited to different styles of development.

SQLAlchemy puts emphasis on the "SQL". It wants to expose every capability of your database and every feature of its SQL dialect, and is heavily oriented around thinking in SQL first and then working your way back to live objects in code.

Django puts emphasis on the "object" side of object-relational mapping; it doesn't aim to be a comprehensive API to your database (since you can just write SQL for that), and moves practically all of the design and interaction up into the Python code layer, then working your way down to the DB as needed.

Or, more succinctly:

* SQLAlchemy: "I have a database and want to interact with it through Python objects".

* Django: "I have Python objects, and would like to use a database as a store for them."

Neither one is objectively the "right" or "wrong" way to approach this, IMHO.

Django 1.1 is out

Related Stories