Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
djangoappengine updates: IN and != queries and DecimalField
Django-nonrel's App Engine backend (djangoappengine) now finally supports all query features available on App Engine. Additionally, we now support DecimalField, thanks to Mariusz Kryński! Let's start with "!=" query support. You can now create queries like this: Post.objects.exclude(category='sql') This has the same behavior as the App Engine code Post.all().filter('category !=', 'sql'). Internally, this actually gets converted into two queries (even with App Engine's native API): "category > 'sql'" and "category < 'sql'". We also now support IN queries like this one: Post.objects.filter(category__in=['django', 'NoSQL']) This has the same behavior as the App Engine code Post.all().filter('category IN', ['django', 'fun']). Again, internally this gets converted into two queries: "category = 'django'" and "category = 'NoSQL'". Note that you can't create queries which would need more than 30 sub-queries. Finally, you can now use DecimalField: from decimal import Decimal from django.db import models class DecimalModel(models.Model): decimal = models.DecimalField(max_digits=9, decimal_places=2) result = DecimalModel.objects.get(decimal=Decimal('45.60')) The difference between decimals and floats is that decimals are exact whereas a floats have rounding errors. For example, if you enter "2.3" this into a Python console you get: >>> 2.3 2.2999999999999998 In contrast, a decimal would stay exactly "2.3". So, what's next? During this Google I/O we might get to … -
django-moderation new release 0.2 - status update
Today i have released new version of django-moderation - 0.2. It has been uploaded in to pypi, so now it can be installed with easy_install. Many bugs were fixed and many new features were added since initial release. List of changes Added GenericModerator class that encapsulates moderation options for a given model.Changed register method, it will get only two parameters: model class and settings class. Added option to register models with multiple managers. Added options to GenericModerator class: auto_approve_for_superusers, auto_approve_for_staff, auto_approve_for_groups, auto_reject_for_anonymous, auto_reject_for_groups. Added methods for checking auto moderation. Added automoderate helper function. Changed moderated_object property in ModerationManager class, moderated object is get only once from database, next is cached in moderatedobject, fixed issue with not setting user object on changed_by attribute of ModeratedObject model. Fixed issue when loading object from fixture for model class that is registered with moderation. Now moderated objects will not be created when objects are loaded from fixture. Fixed issue with TypeError when generating differences of changes between model instances that have field with non unicode value ex. DateField. Fixed issue with accessing objects that existed before installation of django-moderation on model class. Fixed issue when more then one model is registered with moderation and … -
New Django Site – Blog Twin
I created Blog Twin after reading a blog post by Viper Chill entitled The Secret to growing your blog twice as fast with half the effort, I decided to create a site that would help people find a blogging partner. Blog Twin is written in Django (naturally!). You register, add details of your blog, and [...] -
Backend supported Backup/Restore
The current application data is now ready to be backed-up, and restored as and when required.Present application data can now be exported as JSON fixtures, to get a snapshot of the current application datastore state. At present it'll export the following objects:BlogsUsersAuthorsPostsCommentsThe backup scripts uses Django Serialization to store the objects into files, and are deserialized into native python objects when restoring.Thus, now backup and restore of the online project contents is possible. Currently, this can only be done from the backend, but later a more restricted version of it will be available from the front-end too. -
Backend supported Backup/Restore
The current application data is now ready to be backed-up, and restored as and when required.Present application data can now be exported as JSON fixtures, to get a snapshot of the current application datastore state. At present it'll export the following objects:BlogsUsersAuthorsPostsCommentsThe backup scripts uses Django Serialization to store the objects into files, and are deserialized into native python objects when restoring.Thus, now backup and restore of the online project contents is possible. Currently, this can only be done from the backend, but later a more restricted version of it will be available from the front-end too. -
Free to comment
The commenting system is now available.Although it is going to be still under development, and more features might be added to it. It's now totally usable by others, none the less.The current development version of Django does provide a comments framework to work with comments on other existing data models. I still decided not to use it at this point of time. There are two main reasons for that:The comments framework is used as just another Django application (which I don't want to happen in this case), and it's development is not yet stabilized, going through modular and implemention changes.I'm not sure whether I would like to stick to the current system either, and may switch to something like DISQUS. In such a case the porting might be a little less complex.Although I have certain advanced plans for the commenting system, I don't except them to get implemented until a more matured version of ScratchBlog comes through. -
Free to comment
The commenting system is now available.Although it is going to be still under development, and more features might be added to it. It's now totally usable by others, none the less.The current development version of Django does provide a comments framework to work with comments on other existing data models. I still decided not to use it at this point of time. There are two main reasons for that:The comments framework is used as just another Django application (which I don't want to happen in this case), and it's development is not yet stabilized, going through modular and implemention changes.I'm not sure whether I would like to stick to the current system either, and may switch to something like DISQUS. In such a case the porting might be a little less complex.Although I have certain advanced plans for the commenting system, I don't except them to get implemented until a more matured version of ScratchBlog comes through. -
Django 1.2 release notes
Django 1.2 release notes (via). Released today, this is a terrific upgrade. Multiple database connections, model validation, improved CSRF protection, a messages framework, the new smart if template tag and lots, lots more. I’ve been using the 1.2 betas for a major new project over the past few months and it’s been smooth sailing all the way. -
Django Facebook – Open graph API implementation
Update: This blog post is outdated, a new and vastly upgraded version of Django Facebook is now available. Read more about it here. For Fashiolista.com we needed to integrate with the Facebook Open Graph API. The open graph API is a very exciting facebook project, which you can read about more here and here. The code at fashiolista.com allows you to register/login via facebook using the Open Graph API (similar to the old Facebook connect, but registration, instead of only logging in). Before you go try it out, fashiolista.com is aimed primarily at females so your girl friends facebook account is probably a better fit. Im releasing the source code for Django Facebook on github. Its a very early release, but it might help other developers trying to implement a facebook register/loging flow using the new open graph api. See Github for requirements and installation instructions. Update: Birthday formats are currently giving some troubles for some users. Fixed and tests added to prevent future problems. (note Fashiolista.com may still give errors, will be resolved during our next release). Share and Enjoy: -
Index definition mystery
According to the App Engine documentation, the index definitions at index.yaml should be added automatically by the development web server. But, in my current project setup, it's not happening that way, and I have to manually make the entries for it, atleast for the admin application.Now sure whether this is a bug at App Engine, or Django-nonrel, or at my end. But would surely like to get to the bottom of this. And when I do, will get back with more info about it here. -
Index definition mystery
According to the App Engine documentation, the index definitions at index.yaml should be added automatically by the development web server. But, in my current project setup, it's not happening that way, and I have to manually make the entries for it, atleast for the admin application.Now sure whether this is a bug at App Engine, or Django-nonrel, or at my end. But would surely like to get to the bottom of this. And when I do, will get back with more info about it here. -
Cronograna de lançamento do Django 1.2 -- atualização final
Cronograna de lançamento do Django 1.2 -- atualização final -
Cronograna de lançamento do Django 1.2 -- atualização final
Cronograna de lançamento do Django 1.2 -- atualização final -
Ported to Django-nonrel
Working with the google-app-engine-django helper was proving to be of some pain. Not only did I have to write the code twice, it was also getting very hectic to test the application too! So, decided to look for alternatives. After searching through the list of alternative, which wasn't long anyway, I decided to try out Django-nonrel.After going through it's documentations and also trying out it out, finally decided to switch the from the "django-app-engine-django" helper to the "Django-nonrel" port.Although it doesn't yet support all of Django APIs out of the box, but still has support upto a certain acceptible extent. The best part seems to be the way in which the port is supposed to work. And being currently a very active project, it's future and prospect seems good. They're using the lastest version of Django and hacking it's core to get support for non-relational databases and the App Engine database backend.The manage.py looks loaded with many useful common features, other than just the regular ones. Now remote login python shell to the GAE application server is just too easy. Infact the remote feature can be used with it's other subcommands too.Overall, it seemed to be the most promising thing … -
Ported to Django-nonrel
Working with the google-app-engine-django helper was proving to be of some pain. Not only did I have to write the code twice, it was also getting very hectic to test the application too! So, decided to look for alternatives. After searching through the list of alternative, which wasn't long anyway, I decided to try out Django-nonrel.After going through it's documentations and also trying out it out, finally decided to switch the from the "django-app-engine-django" helper to the "Django-nonrel" port.Although it doesn't yet support all of Django APIs out of the box, but still has support upto a certain acceptible extent. The best part seems to be the way in which the port is supposed to work. And being currently a very active project, it's future and prospect seems good. They're using the lastest version of Django and hacking it's core to get support for non-relational databases and the App Engine database backend.The manage.py looks loaded with many useful common features, other than just the regular ones. Now remote login python shell to the GAE application server is just too easy. Infact the remote feature can be used with it's other subcommands too.Overall, it seemed to be the most promising thing … -
IxC workshop May'10
Yesterday we organised another of our monthly workshops. Varied topics were presented and discussed. Brett presented his learning experience during his internship at the IxC. I presented ways for boosting one’s productivity with text expanding, apple scripts and automations. Thomas and Brett showcased some cool features respectively from the LESS CSS framework and Coffee script. George proposed ways for including javascript libraries into reusable Django applications. Greg organised a fun game, based on index cards and “rock-paper-scissors”-style plays, for the agile estimation of feature implementation. This is something we’re actually (seriously!) about to implement in some of our biggest client projects. Those workshops are a great way for the team to share knowledge and good tips and to stay on the edge of all the cool things out there. We’re planning to make them public at some stage, so stay tuned! -
Scratchy Start
Porting this Django application to Google App Engine is proving to be some pain!Initiallialy I had thought that it won't be much of a thing. And since the google-app-engine-django helper was already out there, I thought things won't be that much difficult.Started with including the Django development version, and I just realized that things might not be that easy. Had to switch back to Django 1.1.1 version, and after putting it in place of the SVN version, the helper can launch the django devlopment server, to say the least. The helper still fails in one of the tests it performs, but who cares, my app engine server is up and running and ready to serve Django.The Django Models had to be replaced with the App Engine Models. I'm using the Google App Engine backed datastore, as I'm not willing to spend for hosting yet. The views also had to changed due to the change in APIs from Django to App Engine. The development server is working pretty much fine, and after a little time, the local datastore is created using my simple python scripts.Now the deployment. It was too easy to get the files up here. But, the biggest problem. … -
Scratchy Start
Porting this Django application to Google App Engine is proving to be some pain!Initiallialy I had thought that it won't be much of a thing. And since the google-app-engine-django helper was already out there, I thought things won't be that much difficult.Started with including the Django development version, and I just realized that things might not be that easy. Had to switch back to Django 1.1.1 version, and after putting it in place of the SVN version, the helper can launch the django devlopment server, to say the least. The helper still fails in one of the tests it performs, but who cares, my app engine server is up and running and ready to serve Django.The Django Models had to be replaced with the App Engine Models. I'm using the Google App Engine backed datastore, as I'm not willing to spend for hosting yet. The views also had to changed due to the change in APIs from Django to App Engine. The development server is working pretty much fine, and after a little time, the local datastore is created using my simple python scripts.Now the deployment. It was too easy to get the files up here. But, the biggest problem. … -
This is a sample title
This is a sample content used for testing this new blogging application. The content is being used for testing my new Django application, codenamed as "ScratchBlog". Let's see how it goes through. -
This is a sample title
This is a sample content used for testing this new blogging application. The content is being used for testing my new Django application, codenamed as "ScratchBlog". Let's see how it goes through. -
Getting Random objects from a Queryset in Django
When providing related or suggested info to the user in a website, it’s a common practice to obtain a random set of items. To do this in django the “usual” way is: Book.objects.all().order_by('?')[:10] The above code, sorts all books in a random order and then picks the first 10 objects. This approach is not really [...] -
Django aggregation and a simple GROUP BY
I love Django's aggregation framework. It very successfully abstracts the common aggregration tasks into a Pythonic syntax that sits extremely well with the rest of the ORM, and the documentation explains it all without a single reference to SQL. But sometimes that very abstraction gets in the way of working out what you want to do. One example of this happened to me today when I needed to do a sum of values grouped by a single value on a model - in SQL terms, a simple GROUP BY query. The documentation is very clear about how to do aggregations across an entire QuerySet, and annotations across a relationship. So you can, for example, easily do a sum of all the 'value' fields in a model, or a sum of all the 'value' fields on a related model for each instance of the parent model. But the implication is that these are the only things you can do. So I was left wondering if I had to create a dummy related model just to contain the unique values of the field I wanted to group on. In fact, what I wanted to do was clearly documented, but because of the … -
Django aggregation and a simple GROUP BY
I love Django's aggregation framework. It very successfully abstracts the common aggregration tasks into a Pythonic syntax that sits extremely well with the rest of the ORM, and the documentation explains it all without a single reference to SQL. But sometimes that very abstraction gets in the way of working out what you want to do. One example of this happened to me today when I needed to do a sum of values grouped by a single value on a model - in SQL terms, a simple GROUP BY query. The documentation is very clear about how to do aggregations across an entire QuerySet, and annotations across a relationship. So you can, for example, easily do a sum of all the 'value' fields in a model, or a sum of all the 'value' fields on a related model for each instance of the parent model. But the implication is that these are the only things you can do. So I was left wondering if I had to create a dummy related model just to contain the unique values of the field I wanted to group on. In fact, what I wanted to do was clearly documented, but because of the … -
Gunicorn / Django Debian init script
This is a simple Debian init.d script for my self-hosted Django/Gunicorn websites. Note that it runs inside a virtualenv (my installed Django versions are different in each virtualenv). If you have questions: comment this post! #!/bin/sh ### BEGIN INIT INFO # Provides: seismic_web # Required-Start: $local_fs $syslog # Required-Stop: $local_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Gunicorn processes for seismic_web ### END INIT INFO # www-data is the default www user on debian USER=www-data NAME="seismic_web" GUNICORN_RUN="gunicorn_django" # Confdir: the Django project inside the virtualenv CONFDIR="/home/thomas/seismic_web/seismic_web" VENV_ACTIVATION=". ../bin/activate" RETVAL=0 # PID: I always name my gunicorn pidfiles this way PID="/tmp/gunicorn_"$NAME".pid" # source function library . /lib/lsb/init-functions start() { echo "Starting $NAME." cd $CONFDIR; su -c "$VENV_ACTIVATION; $GUNICORN_RUN" $USER && echo "OK" || echo "failed"; } stop() { echo "Stopping $NAME" kill -QUIT `cat $PID` && echo "OK" || echo "failed"; } reload() { echo "Reloading $NAME:" if [ -f $PID ] then kill -HUP `cat $PID` && echo "OK" || echo "failed"; fi } case "$1" in start) start ;; stop) stop ;; restart) reload ;; reload) reload ;; force-reload) stop && start ;; *) echo $"Usage: $0 {start|stop|restart}" RETVAL=1 esac exit $RETVAL -
Deploying Django project with gunicorn and Nginx
Easy and fast deployment with gunicorn - a WSGI Python HTTP server and super fast and scalable Nginx server.
