Mit Changeset r9742 wurde der lang erwartete Aggregation Support dem Trunk hinzugefügt und wird damit Bestandteil von Django 1.1. sein. Aggregation stellt neue Datenbank-Lookups zur Verfügung, mit dem sich -- in SQL -- Summen-, Durchschnitts-, Minimal- und Maximalwerte einer Spalte/Querysets ermitteln lassen.

Die Dokumentation ist auch schon verfügbar.

Mit Changeset r9739 sind die URLs des Administrationsinterface nun reverse'bar. Um dieses Feature nutzen zu können, muss die Include-Zeile geändert werden:

('^admin/', include(admin.site.urls));

Die alte Syntax bleibt aber weiterhin kompatibel.

Die Liste der Änderungen der Django-Codebasis BackwardsIncompatibleChanges aus dem offiziellen Django-Wiki, die Inkompatibilitäten zu vorigen Django-Versionen vor Version 1.0 aufzeigt, wurde durch die neue Liste FutureBackwardsIncompatibleChanges ersetzt.

In der neuen Liste werden Änderungen für Django 2.0 aufgeführt, die Anpassungen vorhandener Projekt-Codebases aus Inkompatibilitätsgründen zu vorherigen Django-Versionen notwendig macht.

Entwicklern, die weiter auf den Entwicklungszweig trunk setzen, sei ein regelmäßiger Blick auf die neue Liste empfohlen. Derzeit befindet sich dort bereits ein Eintrag, der die Verschiebung der shortcut()-Funktion (r9001) dokumentiert.

Für die Django-Versionen 0.91 bis hin zur aktuellen Trunk-Version wurde gestern ein Security Fix veröffentlicht. Im Detail handelt es sich um eine CSRF Manipulation im Django Admin die dann auftaucht, wenn die Session eines Benutzers abgelaufen ist, die Daten sich aber weiterhin in den POST-Daten befanden. Details findet ihr im Quelllink.

Allen Benutzern ist angeraten, ihre jeweilige Django-Instanz auf den aktuellen Stand zu bringen.

Über die Aufnahme der Reinkarnation von django.contrib.comments in Django 1.0 wurde bereits spekuliert; nun ist sie mit r8557 amtlich.

Thejaswi Puthraya entwickelte große Teile des neuen Systems als Teil des Googles Summer of Code Projekts. Django-newcomments ist das erste GSoC-Projekt, das in django-trunk Einzug hält.

Entwickler, die die bisherige Version von django.contrib.comments einsetzen, wird der zur Verfügung gestellte Upgrade-Guide an's Herz gelegt, da es sich bei dem Commit um eine backwards-incompatible-Veränderung handelt.

Jannis hat soeben die deutsche Übersetzung für django mit r8430 vervollständigt. Sollte noch jemand von euch Fehler finden, bitte eine kurze Info an ihn.

Mit Changeset r8362 ist pünktlich der zweite große Milestone abgeschlossen worden. Django 1.0 beta1 ist die Basis für die in (hoffentlich) 3 Wochen erscheinende Final 1.0. Und was noch viel wichtiger ist: beta1 ist feature-freeze!

Entwickler die in den letzten Tagen regelmäßig ihre Trunk-Version aktualisiert haben, waren manchmal sicherlich genervt, Signals- und Filestorage-Refactor betraten die Bühne und waren beide Backwards Incompatible.

Mit der beta1 ist nun aber ein festes Fundament geschaffen worden, Entwicklern die Möglichkeit zu geben, ihre Applikationen auf die bevorstehende Version 1.0 zu aktualisieren. Die diversen, freien Django-Apps dürften in Kürze nachziehen.

Wurde mit r7798 erst vor wenigen Wochen der __exact-Filter auf case-sensitive umgestellt, ist heute mit r8319 die Änderung revidiert worden. Begründet wird dies mit tabellenspezifischen Konfigurationen, an die sich __exact ab sofort halte. Abhängig von der jeweiligen Kollation passe sich __exact entsprechend an und arbeite case-sensitive oder case-insensitive. Informationen, welche Kollation man am Besten für seine jeweiligen Tabellen einsetzen sollte und welche Kollationen für ein case-sensitive-Verhalten sorgen, erhält man in der Datenbankdokumentation.

Als besonders heimtückisch erweisen sich solche backwards-incompatible-Veränderungen mit gleichbleibendem Namen und ohne Änderungshinweis beim Start der Django-Anwendung mit dem Resultat, dass der Entwickler respektive der Nutzer möglicherweise vor ungewöhnliche und erstmal unerklärliche Probleme gestellt wird. Nutzern von trunk wird daher besonders empfohlen, regelmäßig Veränderungen an der Codebase mitzuverfolgen.

Anlässlich der bald erscheinenden Version 1.0 wurden einige bisher veraltete Unterstützungen aus dem aktuellen Trunk entfernt, die möglicherweise eine Anpassung vorhandener Projekte beim Umstieg auf Django 1.0 respektive Trunk nötig machen.

Die wichtigsten Änderungen im Überblick:

• Dateien werden ab sofort nur noch über django.core.files.base.ContentFile repräsentiert (ehemals als String)

• Attribute des UploadFile wurden vereinheitlicht (ab sofort name, size, chunks)

• umbenannt wurden auch die Attribute der Klassen FileField/ImageField (ab sofort path, url, size bzw. width, height (ehemals get_X_Y-Methoden)

• form_for_model/form_for_instance wurden entfernt. Ersatz: Subclassing von ModelForm unter Angabe des Models in der Subklasse Meta

• django.newforms und django.utils.images heißen nun endgültig django.forms sowie django.core.files.images

Weitere Veränderungen sind der Quelle zu entnehmen (Eintrag in der Liste der backwards-incompatible changes).

Die Überarbeitung der Django-Filehandling-Routinen erlaubt ab sofort eine dynamische Verarbeitung von hochgeladenen Dateien. So ist es beispielsweise möglich, Dateien nicht mehr notwendigerweise auf dem lokalen Dateisystem ablegen zu müssen, sondern direkt an einen entfernten Dateidienst wie Amazons S3 übertragen zu können (siehe dazu auch django-storages).

Zu diesem Zweck können weitere Storage-Klassen eingeführt werden, die die Interaktion und Verarbeitung übernehmen. Django liefert standardmäßig nur eine solche Klasse, FileSystemBackend, mit, die, wie bisher gewohnt, mit dem lokalen Dateisystem arbeitet.

Es handelt sich beim FileStorageRefactor um eine backwards-incompatible-Veränderung, die eine Anpassung bisheriger Projekte möglicherweise notwendig macht. Nähere Informationen zu diesen Veränderungen finden sich hier.