Am Rande notiert ...

toastdriven/django-tastypie. Hatte ich glaube ich schon mal, macht aber nix, sieht immer noch interessant aus – eine Alternative zu django-piston mit einer deutlich weitergehenden Funktionalität (zum Beispiel recht ausführliche Optionen für Authentifizierung und Authorisierung). Was es macht? REST Interfaces für Django Modelle inklusive deren Relationen. In den verschiedensten Formaten (XML, JSON, YAML).

Make runfcgi fail when database connection is open before fork. Das ist eine Sache nach der ich schon ewige Zeiten jage, zuletzt in ein paar ziemlich wichtigen Projekten. Flup arbeitet so, dass es die WSGI-Anwendung erst initialisiert und mit dieser initialisierten WSGI Anwendung dann die Forks für die Worker macht. Dummerweise gibt es bei uns aber Datenbankzugriffe wärend der Anwendungsinitialisierung – dadurch hat der Basisprozess schon eine offene Datenbankverbindung, jeder Fork kopiert diese Daten. Aber der Socket der Verbindung geht natürlich nicht mit – der neue Prozess denkt nur er wäre verbunden, ist es aber nicht. Zugriffe von denen neuen Prozessen fallen dann mit einer Exception raus. Man kann im verlinkten Patch auch gut den raise auf die Exception einfach durch connection.connection = None ersetzen. Dann wird einfach die Verbindung die sowieso defekt ist weggeworfen und in neuen Prozessen immer eine neue Verbindung aufgebaut. Damit haben wir zumindestens in einem Produktionsumfeld (mit psycopg2) das ganze beheben können und sind guten Mutes, dass es auch bei der Umgebung  mit pyodbc helfen wird.

#18251 multithreading deadlock in django.models.loading.get_apps – Django. Und noch eine Sache, die uns vielleicht betreffen könnte – Raceconditions zwischen Django-Threads bei der Initialisierung von Django-Applications. Gibt auch schon einen Patch dafür, der das in den Django Internals behebt.

Using SELECT FOR UPDATE in Django. Drin was dran steht. Denn der Django ORM kann derzeit keinen SELECT FOR UPDATE erzeugen, aber manchmal braucht man ihn einfach.

uWSGI. Hatte ich scheinbar noch nicht – ein Kollege hat mich gerade darauf hingewiesen. Könnte besonders für Django-Projekte interessant sein, weil es wesentlich flexiblere Prozesssteuerung und Monitoring bietet als der flup-basierte runfcgi in Django.

Radius limited searching with the ORM | Neogeo ramblings with a Python twist. Wenn ich mir das so angucke, da sind schon wirklich nette Features in GeoDjango drin. Leider habe ich derzeit kein Projekt bei dem ich es gebrauchen könnte, also nur mal für später geblogmarkt. Auf dem Blog gibts auch weitere interessante Artikel rund um GeoDjango.

Pinax. Und wieder mal was das ich glaube ich schon hatte. Aber aus aktuellem Grund nochmal auf den Radar gekommen und daher werde ich mir das etwas näher angucken. Sowas wie ein Bauchladen für Django-Projekte mit Fokus auf Social Networks und Community Sites. Klingt auf jeden Fall sehr interessant – ein bischen wirkt es wie Drupal mit Python und auf Django (also eher nicht fertige Sites sondern Bausteine und Framework zur Erstellung derselben).

Django Facebook 2.0 – Integrating Facebook. Weils im Moment interessant ist (jaja, ich weiss, alles macht G+, aber man soll ja antizyklisch handeln), hier ein Link zu einer Django-Library mit der man Open Graph Apps für Facebook bauen kann. Könnte gerade zusammen mit der neuen Timeline von Facebook wieder interessant werden. Und G+? Naja, solange die nur armselige Spar-APIs liefern, ist das für Bastler schlichtweg uninteressant.

Django-nonrel – NoSQL support for Django. Liefert einen ersten Ansatz in Django verschiedene NoSQL Datenbanken zu integrieren, und zwar auf Ebene des Django-ORM. Backends für MongoDB (nein Danke), AppEngine und Cassandra sind in der Mache. Besonders Cassandra interessiert mich im Moment.

chrisdickinson’s wilson. Einen noch vor dem Mittagessen, denn das Framework orientiert sich stark an Django, und da ich ja Django-Fan bin, ist das sicherlich einen eigenen Link wert.