Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Updates for django-lastfm and django-sphinxdoc
After reading The Hitchhiker’s Guide to Packaging I update my packages for django-lastfm and django-sphinxdoc. There are no functionional improvements, so you don’t need to update them. -
Announcing django-moderation
django-moderation is reusable application for Django framework, that allows to moderate any model objects. Code can be found at http://github.com/dominno/django-moderation Possible use cases: User creates his profile, profile is not visible on site. It will be visible on site when moderator approves it. User changes his profile, old profile data is visible on site. New data will be visible on site when moderator approves it. Features: configurable admin integration(data changed in admin can be visible on site when moderator approves it) moderation queue in admin html differences of changes between versions of objects configurable email notifications custom model form that allows to edit changed data of object 100% PEP8 correct code test coverage > 80% Requirements python >= 2.4 django >= 1.1 Installation Download source code from http://github.com/dominno/django-moderation and run installation script: $> python setup.py install Configuration Add to your INSTALLED_APPS in your settings.py: moderation Run command manage.py syncdb Register Models with moderation from django.db import models from moderation import moderation class YourModel(models.Model): pass moderation.register(YourModel) Register admin class with your Model from django.contrib import admin from moderation.admin import ModerationAdmin class YourModelAdmin(ModerationAdmin): """Admin settings go here.""" admin.site.register(YourModel, YourModelAdmin) If you want to disable integration of moderation in admin, add admin_intergration_enabled = … -
Decoupled Django Apps and the Beauty of Generic Relations
Like just about everyone else, we've written our own suite of tools to help with building complex content management systems in Django here at Caktus. We reviewed a number of the existing CMSes out there, but in almost every case the navigation and page structure were so tightly coupled the system broke down when it came time to add additional, non-CMS pages. -
Cache Machine: Automatic caching for your Django models
Cache Machine: Automatic caching for your Django models. This is the third new ORM caching layer for Django I’ve seen in the past month! Cache Machine was developed for zamboni, the port of addons.mozilla.org to Django. Caching is enabled using a model mixin class (to hook up some post_delete hooks) and a custom caching manager. Invalidation works by maintaining a “flush list” of dependent cache entries for each object—this is currently stored in memcached and hence has potential race conditions, but a comment in the source code suggests that this could be solved by moving to redis. -
Django User Profiles - Simple yet powerful
So you're building a web application, and using the excellent contrib.auth subsystem to manage user accounts. Most probably you need to store additional information about your users, but how? Django profiles to the rescue! Django provides a lightweight way of defining a profile object linked to a given user. The profile object can differ from project to project, and it can even handle different profiles for different sites served from the same database. In a nutshell, using Django profiles consists of 3 steps: Define a model that holds the profile information. Tell Django where to look for the profile object. Create the user profile as needed. Defining the user profile model The only requirement Django places on this model is that it have a unique ForeignKey to the User model, and is called user. Other than that, you can define any other fields you like. For our example, we'll create 2 user profile fields (url and company). account/models.py from django.db import models from django.contrib.auth.models import User class UserProfile(models.Model): user = models.ForeignKey(User, unique=True) url = models.URLField("Website", blank=True) company = models.CharField(max_length=50, blank=True) Tell Django about the profile object Accessing a users profile is done by calling user.get_profile(), but in order … -
Django User Profiles - Simple yet powerful
So you're building a web application, and using the excellent contrib.auth subsystem to manage user accounts. Most probably you need to store additional information about your users, but how? Django profiles to the rescue! Django provides a lightweight way of defining a profile object linked to a given user. The profile object can differ from project to project, and it can even handle different profiles for different sites served from the same database. In a nutshell, using Django profiles consists of 3 steps: Define a model that holds the profile information. Tell Django where to look for the profile object. Create the user profile as needed. Defining the user profile model The only requirement Django places on this model is that it have a unique ForeignKey to the User model, and is called user. Other than that, you can define any other fields you like. For our example, we'll create 2 user profile fields (url and company). account/models.py from django.db import models from django.contrib.auth.models import User class UserProfile(models.Model): user = models.ForeignKey(User, unique=True) url = models.URLField("Website", blank=True) company = models.CharField(max_length=50, blank=True) Tell Django about the profile object Accessing a users profile is done by calling user.get_profile(), but in order … -
Django User Profiles - Simple yet powerful
So you're building a web application, and using the excellent contrib.auth subsystem to manage user accounts. Most probably you need to store additional information about your users, but how? Django profiles to the rescue! Django provides a lightweight way of defining a profile object linked to a given user. The profile object can differ from project to project, and it can even handle different profiles for different sites served from the same database. In a nutshell, using Django profiles consists of 3 steps: Define a model that holds the profile information. Tell Django where to look for the profile object. Create the user profile as needed. Defining the user profile model The only requirement Django places on this model is that it have a unique ForeignKey to the User model, and is called user. Other than that, you can define any other fields you like. For our example, we'll create 2 user profile fields (url and company). account/models.py from django.db import models from django.contrib.auth.models import User class UserProfile(models.Model): user = models.ForeignKey(User, unique=True) url = models.URLField("Website", blank=True) company = models.CharField(max_length=50, blank=True) Tell Django about the profile object Accessing a users profile is done by calling user.get_profile(), but in order … -
Refugee Buddy: a project of OzSiCamp Sydney 2010
Last weekend, I attended Social Innovation Camp Sydney 2010. SiCamp is an event where several teams have one weekend in which to take an idea for an online social innovation technology, and to make something of it. Ideally, the technology gets built and deployed by the end of the camp, but if a team doesn't reach that stage, simply developing the concept is an acceptable outcome as well. I was part of a team of seven (including our team leader), and we were the team that built Refugee Buddy. As the site's slogan says: "Refugee Buddy is a way for you to welcome people to your community from other cultures and countries." It allows regular Australians to sign up and become volunteers to help out people in our community who are refugees from overseas. It then allows refugee welfare organisations (both governmnent and independent) to search the database of volunteers, and to match "buddies" with people in need. Of the eight teams present at this OzSiCamp, we won! Big congratulations to everyone on the team: Oz, Alex, James, Daniela, Tom, (and Jeremy — that's me!) and most of all Joy, who came to the camp with a great concept, and … -
Easy create or update
One common database operation that isn't supported out of the box by Django's ORM is create_or_update - in other words, given a set of parameters, either update an existing object or create a new one if there isn't one already. The naive implementation is to do a get() on the model, catching the DoesNotExist exception if there's no match and instantiating a new object, then updating the attributes and saving. (You wouldn't want to use get_or_create here, as that doesn't allow you to update the instance if it already exists, so you'd have some duplication of code and db queries). try: obj = MyModel.objects.get(field1=value1) except MyModel.DoesNotExist: obj = MyModel() obj.field1 = field1 obj.field2 = value2 obj.save() The only problem with this is that it creates multiple queries: one to get the existing row, and then two to save it - Django checks to see if it should do an insert or an update when you save, which costs another query. Most of the time, this doesn't massively matter: creating and updating is usually done outside of the standard page rendering flow, so it's not a huge problem if it's a tiny bit slower. But there are times when you do … -
Einladung zur Django-UserGroup Hamburg am 23. März
Das nächste Treffen der Django-UserGroup Hamburg findet am Dienstag, den 23.03.2010 um 19:30 statt. Wie bei den letzten Malen treffen wir uns wieder in den Räumen der CoreMedia AG in der Ludwig-Erhard-Straße 18 in 20459 Hamburg (Anfahrtsbeschreibung auf Google Maps). Bitte am Eingang bei CoreMedia AG klingeln, in den 3. Stock fahren und oben am Empfang nach der Django-UserGroup fragen. Da wir in den Räumlichkeiten einen Beamer zur Verfügung haben hat jeder Teilnehmer die Möglichkeit einen kurzen Vortrag (Format: Lightning Talks oder etwas länger) zu halten. Die meisten Vorträge ergeben sich erfahrungsgemäß vor Ort. Eingeladen ist wie immer jeder der Interesse hat sich mit anderen Djangonauten auszutauschen. Eine Anmeldung ist nicht erforderlich. Weitere Informationen über die UserGroup gibt es in unserem Git Repository unter www.dughh.de und im Wiki des Deutschen Django-Vereins. -
Easy create or update
One common database operation that isn't supported out of the box by Django's ORM is create_or_update - in other words, given a set of parameters, either update an existing object or create a new one if there isn't one already. The naive implementation is to do a get() on the model, catching the DoesNotExist exception if there's no match and instantiating a new object, then updating the attributes and saving. (You wouldn't want to use get_or_create here, as that doesn't allow you to update the instance if it already exists, so you'd have some duplication of code and db queries). try: obj = MyModel.objects.get(field1=value1) except MyModel.DoesNotExist: obj = MyModel() obj.field1 = field1 obj.field2 = value2 obj.save() The only problem with this is that it creates multiple queries: one to get the existing row, and then two to save it - Django checks to see if it should do an insert or an update when you save, which costs another query. Most of the time, this doesn't massively matter: creating and updating is usually done outside of the standard page rendering flow, so it's not a huge problem if it's a tiny bit slower. But there are times when you do … -
Easy create or update
One common database operation that isn't supported out of the box by Django's ORM is create_or_update - in other words, given a set of parameters, either update an existing object or create a new one if there isn't one already. The naive implementation is to do a get() on the model, catching the DoesNotExist exception if there's no match and instantiating a new object, then updating the attributes and saving. (You wouldn't want to use get_or_create here, as that doesn't allow you to update the instance if it already exists, so you'd have some duplication of code and db queries). try: obj = MyModel.objects.get(field1=value1) except MyModel.DoesNotExist: obj = MyModel() obj.field1 = field1 obj.field2 = value2 obj.save() The only problem with this is that it creates multiple queries: one to get the existing row, and then two to save it - Django checks to see if it should do an insert or an update when you save, which costs another query. Most of the time, this doesn't massively matter: creating and updating is usually done outside of the standard page rendering flow, so it's not a huge problem if it's a tiny bit slower. But there are times when you do … -
Continuous Integration with Django and Hudson CI (Day 1)
We're always looking for new tools to make our development environment more robust here at Caktus. We write a lot of tests to ensure proper functionality as new features land and bug fixes are added to our projects. The next step is to integrate with a continuous integration system to automate the process and regularly check that status of the build. -
Announcing twod.wsgi: Better WSGI support for Django
We are very pleased to announce the first alpha release of twod.wsgi, a library to make WSGI a first-class citizen in Django applications.twod.wsgi allows Django developers to take advantage of the huge array of existing WSGI software, to integrate 3rd party components which suit your needs or just to improve things which are not within the scope of a Web application framework.It ships with a PasteDeploy application factory (which gives the enterprise some of what it needs) and full-featured request objects extended by WebOb. It also gives you the ability to serve WSGI applications inside Django, so you can filter the requests they get and/or the responses they return (e.g., to implement Single Sign-On mechanisms). And there's more!For example, if you wanted to integrate your authentication mechanisms with your Trac application, you could do it in 11 lines of code:from django.shortcuts import redirectfrom django.conf import settingsfrom twod.wsgi import call_wsgi_appfrom trac.web.main import dispatch_request as trac_appdef make_trac(request, path_info): if path_info.startswith("/login"): return redirect(request.script_name + "/login") elif path_info.startswith("/logout"): return redirect(request.script_name + "/logout") request.environ['trac.env_path'] = settings.TRAC_PATH return call_wsgi_app(trac_app, request, path_info)Don't be fooled by the "first alpha release": It's rock-solid. We've been using it for months in our Web site and it's never ever failed. It … -
Debugging production Django deployment
Deploying Django is a process that can drive one bananas. There are a lot of things to setup to go from your development environment to the production. Aside from the regular hassles - there come special little buggers that can really make you mad. If you ever had problems with 500.html pages, url configurations or import errors - you know what I mean. However it doesn't all have to be that bad. There are quite a few steps you can take early on to minimize the pain. If you do get into trouble - there are some things you can do to debug out of it. Preventative Measures Deploy early If you want to avoid the hassle of debugging 100 things at once, deploy your project as soon as possible. By "as soon as possible" I mean right after you create it - when there are no models, views and funky url settings! Commit often You are of course using source control for your project, correct? By committing often you allow for greater granularity of your project. In a way you "isolate" bugs in a particular commit. This makes finding them later on particularly easy. Deploy often Same as #1 - … -
Announcing django-cachebot
Announcing django-cachebot. The ORM caching space around Django is heating up. django-cachebot is used in production at mingle.com and takes a more low level approach to cache invalidation than Johnny Cache, enabling you to specifically mark the querysets you wish to cache and providing some advanced options for cache invalidation. Unfortunately it currently relies on a patch to Django core to enable its own manager. -
libjpeg symbol not found error with PIL on 10.6 Snow Leopard
If you get the following error, while Installing PIL on Mac OS X 10.6 Snow Leopard read on for a possible solution: >>> from PIL import _imaging Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: dlopen(/Library/Python/2.6/site-packages/PIL/_imaging.so, 2): \ Symbol not found: _jpeg_resync_to_restart Referenced from: /Library/Python/2.6/site-packages/PIL/_imaging.so Expected in: flat namespace in /Library/Python/2.6/site-packages/PIL/_imaging.so Popular how-tos on the web indicated that it is neccessary to force Python on Snow Leopard in 32bit mode to be able to install the Psycopg2 adapter for PostgreSQL. So you might have used the following command on your system: defaults write com.apple.versioner.python Prefer-32-Bit -bool yes Now you get the traceback shown above while installing or using PIL. This might result from an _imaging.so module (for PIL) build with a 64bit version of libjpeg, which now fails to load in a 32bit python interpreter. We were able to solve the problem by installing a universal libjpeg package, found here: http://ethan.tira-thompson.org/Mac_OS_X_Ports.html and recompiling PIL to use this libjpeg version. Now PIL works in 32bit and 64bit mode. -
Pycon 2010 report III: Sprints
My report for the sprints of Pycon 2010. This isn't a general review of the sprints, just how it affected me.Pinax SprintI don't have a hard count of how many people participated on Pinax this year. Last year's sprint looked like we had a lot more, but last year the Pinax room was home to people doing other things, albeit mostly Django related stuff. In any case, this year we had probably about 10 people working on Pinax, or things that went directly into Pinax.While James Tauber is the leader of the Pinax community, this year Brian Rosner stepped up and did an amazing job being both a technical resource and director of geeks. The mutual clarity of vision and obvious telepathy between Brian and James is truly a joy to behold. I also appreciate the entire Pinax community. Besides coaching me on Git branches (work uses SVN so I just don't get enough Git practice) they also gracefully understood that I was a bit distracted this year. My specific contributions to PinaxOne of the things that had bugged me about Pinax for some time were the individual project tag apps. These were a per project extension of django-tagging, and … -
Developing Reusable Django Apps: Signals
I wrote “signals provide a great way to propagate the events generated from your app” earlier. I think reusable apps should avoid hardcoding any kind of event handling and send signals instead. App consumers might prefer an email over an on-screen notification. They may even choose to ignore the event silently. A reusable app should [...] -
Django query set iterator – for really large, querysets
When you try to iterate over a query set with about 0.5 million items (a few hundred megs of db storage), the memory usage can become somewhat problematic. Adding .iterator to your query set helps somewhat, but still loads the entire query result into memory. Cronjobs at YouTellMe.nl where unfortunately starting to fail. My colleague [...] -
Faster, Export and the Shop!
This week saw a boost in speed, the ability to export your recipes and the addition of The Shop, along with the usual smattering of bugfixes. Performance We heard the pleas for quicker pageloads and made some performance enhancements to Forkinit. For the curious, we were previously running with next to no caching on a small server. We upped the size on the server and dropped a little bit of caching in several places on the site. We've already seen 50-75% drops in page load time, which was encouraging. Export Newly on everyone's dashboard is an "export" link. Clicking on that link will allow you to download a file of all of your recipes on Forkinit. Each person only has access to their own recipes. The export file is comma-delimited, which Excel can read just fine. It's important to us that your recipes be your own, and that includes not locking you in to Forkinit. Further, it's a great way to make sure that no matter what happens to us, you've got your recipes. The Shop We've also added The Shop to Forkinit. Currently, it's strictly product recommendations, things we own and find useful. They should be a little intelligent … -
Updates on djangoappengine
This post is a short update on new features we've added to our App Engine backend djangoappengine. So let's plunge in at the deep end. :) New Features First we added support for ListFields. You can use them in combination with any Django field type. Let's say you want to add a ListField for strings to one of your models: class Post(models.Model): words = ListField(models.CharField(max_length=500)) title = models.CharField(max_length=200) content = models.TextField(blank=True) It's as easy as that. Validation for ListFields is done on each entry in the list using the field type specified. The example above uses CharField's validation. ListFields now allows us to write many applications we couldn't write before. One example is a geolocation app. It should be possible to port geomodel or mutiny using native Django only now. We've put ListField into djangotoolbox.fields (see djangotoolbox repository). The next feature added is QuerySet.values() support though it's only efficient on primary keys. Let's see an example using the Post model from above: android_posts = Post.objects.filter(words='android').values('pk') This will get only the primary keys of all posts including the word "android" without fetching the entities from the database itself. It's possible to use QuerySet.values() on other fields than the primary key too … -
Django Up In Your CRON
For one off scripts for a particular project: #!/usr/bin/env python from django.core.management import setup_environ from myapp import settings setup_environ(settings) # do some stuff Related posts:Setup Python 2.5, mod_wsgi, and Django 1.0 on CentOS 5 (cPanel) Getting Started with Django and Python – First Impressions Adventures in Django and Python – Part III Related posts:Setup Python 2.5, mod_wsgi, and Django 1.0 on CentOS 5 (cPanel) Getting Started with Django and Python – First Impressions Adventures in Django and Python – Part III -
Is johnny-cache for you?
Is johnny-cache for you?. “Using Johnny is really adopting a particular caching strategy. This strategy isn’t always a win; it can impact performance negatively”—but for a high percentage of Django sites there’s a very good chance it will be a net bonus. -
'self' ForeignKeys always result in a JOIN
'self' ForeignKeys always result in a JOIN
