4 ms·
Django 1.1 is out
- mtrichardson 17y agoDownload URL: http://www.djangoproject.com/download/1.1/tarball/ http://www.djangoproject.com/download/1.1/tarball/
- shabda 17y agoAnd the weblog entry. http://www.djangoproject.com/weblog/2009/jul/29/1-point-1/ http://www.djangoproject.com/weblog/2009/jul/29/1-point-1/
- forsaken 17y agoAnd that's the way it is. Gotta love the journalism history of the framework coming through :)
- jokull 17y agoModel 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.
- smithjchris 17y agoModel 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.
- ubernostrum 17y agosupport 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.
- smithjchris 17y agoIn single table inhertance, any leaf node from the inheritance graph cannot solely contain a relation to another object. It has to be on the abstract base or the ORM dies when building inserts for other leaf nodes. That leaves you to implement any business constraints on the model, but there is no model validation so it gets shifted into the controllers (or views as they call them). Not overly good.
- ubernostrum 17y agoPerhaps I'm misunderstanding you, but I regularly use abstract classes with subclasses which add relationships to other things, and I've not seen this problem.
- smithjchris 17y agoI'll write a test case and report it at some point. It's on my TODO. Also it's not been tried against 1.1 yet.
- chairface 17y agoThe 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 17y agoCan you give an example of what you mean?
- kingkilr 17y agoI think what he wants is instead of defining a table that a model maps to he could also just definea SQL query to select from. This is somewhat possible with Django 1.1 if you use a DB level view and unmanaged models.
- ubernostrum 17y agoAs 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.