Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
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 -
twod.wsgi Presentation at the Django User Group in London
Last week I had the pleasure to present twod.wsgi, a library to improve WSGI support in Django, at the Django User Group in London. The slides are now available in OpenDocument and PDF formats.That day I used a demo application which we are going to publish, possibly on Bitbucket. We should be releasing twod.wsgi very soon, as soon as the documentation is finished. So stay tuned! -
jmoiron.net: Johnny Cache
jmoiron.net: Johnny Cache. The blog entry announcing Johnny Cache (“a drop-in caching library/framework for Django that will cache all of your querysets forever in a consistent and safe manner”) to the world. -
Pycon 2010 report II
The first half day report for formal conference activities on February 21.Plenary: IntroductionI helped in registration so I arrived late to listen to Van Lindburgh start the conference. Which was a shame because I like to listen to him speak. Nevertheless, I consoled myself with the knowledge that I had contributed my time and service to help him launch what turned out to be an amazing conference.Keynote: Steve HoldenIn December Steve had presented to the NOVA-Django a much earlier draft of his speech. As much as his stuff back in December was good, what he did at Pycon was right on the money. He was in fine form, and the conclusion was very much Steve Holden at his best.The next night Steve was in rare fine form, but that is a story for another day...Keynote: Guido Van RossumBeing that I am Guido's biggest fan, and have trouble breathing in his presence, you might think I'm a bit biased. Alas, in this case, Guido's talk was not my favorite of the conference. If memory serves, at last year's Pycon he mentioned a desire to remove the "For Life" from BDFL and this year I think that showed a little bit. It … -
Django template2pdf
Django template2pdf -
Johnny Cache
Johnny Cache. Clever twist on ORM-level caching for Django. Johnny Cache (great name) monkey-patches Django’s QuerySet classes and caches the result of every single SELECT query in memcached with an infinite expiry time. The cache key includes a “generation” ID for each dependent database table, and the generation is changed every single time a table is updated. For apps with infrequent writes, this strategy should work really well—but if a popular table is being updated constantly the cache will be all but useless. Impressively, the system is transaction-aware—cache entries created during a transaction are held in local memory and only pushed to memcached should the transaction complete successfully. -
Django Management.tmbundle
Did some work on my [Django Management.tmbundle][1] last night. It now handles running tests when (a) The apps are not directly in the project root, but inside another folder, for instance; and (b) the app/tests.py file has been split into seperate files. The main reason I made this was so that I could run tests and have clickable links in the results window for the location of failing tests. There is still much to do on this. I am considering re-writing it in python rather than ruby, so I can programmatically find the app name, rather than guess it. I also want to refactor the hell out of it and make it much nicer. Anyway, if you are interested, you can find the most recent version at [http://github.com/schinckel/Django-Management.tmbundle][1] - and I think it also appears in TextMate's getBundles bundle. [1]: http://github.com/schinckel/Django-Management.tmbundle -
Dynamic form generation
I had the pleasure of being on a forms panel at PyCon 2010 chaired by Brandon Craig Rhodes. To get a stable baseline, Brandon asked each of us to provide code showing how each forms toolkit might tackle a problem: Imagine that someone has already written a form with your forms library. The form looks something like this: New username: __________ Password: __________ Repeat password: __________ [Submit] Now, someone from Marketing comes along and announces that the developers must add some additional questions to the form - and the number of extra questions is not determined until runtime! -
The darker side of Pinax
I really like the concept of Pinax, but I’m beginning to see the darker sides of the project. Here’s the fundamental issue: Pinax does a completely kick ass job of making a combined and base project that pulls together a … Continue reading →
