Most of the time, whenever I hit a website that looks "bubbly" in nature, and all prettified in those pastel-like colors, I think to myself, "This was probably done with Rails." And, lo and behold, after some digging into the site's information pages I discover this is actually true. So, I pose the question, not knowing much about Rails but enough about Django to understand how the database stuff works:

Does RoR have any display-specific qualities that affect how a web page looks? Or do all RoR devs naturally use the same Adobe tools to make everything look so ubiquitous?

Ruby on Rails is a server side technology, so it doesn't lend any specific quality to the user visible design. That said, it is a "trendy" technology so people who are likely to write their back-end code with RoR are likely to choose a particular "Web 2.0" style for their views.

It's kind of like saying "I notice that douches tend to wear backwards baseball caps and wear really baggy jeans. Does wearing a backwards baseball cap affect the tightness of one's jeans?" And the answer would be, no, however, a douche is likely to choose both of these clothing items.

I'm trying to use django, and mongoengine to provide the storage backend only with GridFS. I still have a MySQL database.

I'm running into a strange (to me) error when I'm deleting from the django admin and am wondering if I am doing something incorrectly.

my code looks like this:

# settings.py
from mongoengine import connect
connect("mongo_storage")

# models.py
from mongoengine.django.storage import GridFSStorage
class MyFile(models.Model):
    name = models.CharField(max_length=50)
    content = models.FileField(upload_to="appsfiles", storage=GridFSStorage())
    creation_time = models.DateTimeField(auto_now_add=True)
    last_update_time = models.DateTimeField(auto_now=True)

I am able to upload files just fine, but when I delete them, something seems to break and the mongo database seems to get in an unworkable state until I manually delete all FileDocument.objects. When this happens I can't upload files or delete them from the django interface.

From the stack trace I have:

/home/projects/vector/src/mongoengine/django/storage.py in _get_doc_with_name
        doc = [d for d in docs if getattr(d, self.field).name == name] ...
▼ Local vars
Variable    Value
_[1]    
[]
d   

docs    
Error in formatting: cannot set options after executing query
name    
u'testfile.pdf'
self    

/home/projects/vector/src/mongoengine/fields.py in __getattr__
        raise AttributeError 

Am I using this feature incorrectly?

I think you are better off not using MongoEngine for this, I haven't had much luck with it either. Here is a drop-in replacement for mongoengine.django.storage.GridFSStorage, which works with the admin.

from django.core.files.storage import Storage
from django.conf import settings

from pymongo import Connection
from gridfs import GridFS

class GridFSStorage(Storage):
    def __init__(self, host='localhost', port=27017, collection='fs'):
        for s in ('host', 'port', 'collection'):
            name = 'GRIDFS_' + s.upper()
            if hasattr(settings, name):
                setattr(self, s, getattr(settings, name))
        for s, v in zip(('host', 'port', 'collection'), (host, port, collection)):
            if v:
                setattr(self, s, v)
        self.db = Connection(host=self.host, port=self.port)[self.collection]
        self.fs = GridFS(self.db)

    def _save(self, name, content):
        self.fs.put(content, filename=name)
        return name

    def _open(self, name, *args, **kwars):
        return self.fs.get_last_version(filename=name)

    def delete(self, name):
        oid = fs.get_last_version(filename=name)._id
        self.fs.delete(oid)

    def exists(self, name):
        return self.fs.exists({'filename': name})

    def size(self, name):
        return self.fs.get_last_version(filename=name).length

GRIDFS_HOST, GRIDFS_PORT and GRIDFS_COLLECTION can be defined in your settings or passed as host, port, collection keyword arguments to GridFSStorage in your model's FileField.

I referred to Django's custom storage documenation, and loosely followed this answer to a similar question.

I'm wondering about the advantages of using (django) South during heavy initial development of a project.

At the early stages of development there's normally rapid model changing, frequent branching and merging (especially if you use a development strategy like git-flow) and very little, if any, stored data. Why would you want to keep of these initial model changes? What are the advantages/disadvantages?

I'm under the impression that it's easier to wait until the development settles down (and you have data you actually want to keep) before activating South and performing an initial migration. Is it possible to do that? Would you want to do that?

As soon as I am about push a commit that other people need to use, I create a migration so they can still have a working copy.

If you are working alone(and not worrying about deployment), this is not an issue and you can wait until the last possible moment to create a migration.

Once you begin working with others, it makes life easier to quickly make migrations so it becomes a workflow habit and everyone is on the same database page.

Also, syncdb is not an option if you are simply modifying a field. It gets incredibly annoying to have to blow away a table just for adding, deleting or modifying fields.

If I have a bunch of schema migrations that I added, sometimes I will combine them(rollback and delete them and create a new jumbo migration) into a single migration. But normally, the number of migrations doesn't bother me because they don't cost me anything really.

I'm looking for a good Django custom storage backend for use with Amazon S3.

I've been googling around and found a lot of blog posts with code snippets or half-baked gist.github.com one-off jobs. But I can't seem to find a solid, well-tested one.

Is there a widely accepted standard Amazon S3 Django custom storage backend out there? It doesn't particularly matter to me what Python backend library it uses--i.e., either S3.py or boto are fine.

Have you checked out django-storages? I would lean towards the boto library as I have had good experiences with boto.

I have a need to store a python set in a database for accessing later. What's the best way to go about doing this? My initial plan was to use a textfield on my model and just store the set as a comma or pipe delimited string, then when I need to pull it back out for use in my app I could initialize a set by calling split on the string. Obviously if there is a simple way to serialize the set to store it in the db so I can pull it back out as a set when I need to use it later that would be best.

If your database is better at storing blobs of binary data, you can pickle your set. Actually, pickle stores data as text by default, so it might be better than the delimited string approach anyway. Just pickle.dumps(your_set) and unpickled = pickle.loads(database_string) later.

I recently deployed a couple of web applications built using django (on webfaction). These would be some of the first projects of this scale that i am working on, so I wanted to know what an effective backup strategy was for maintaining backups both on webfaction and an alternate location.

EDIT:

What i want to backup?

Database and user uploaded media. (my code is managed via git)

I'm not sure there is a one size fits all answer especially since you haven't said what you intend to backup. My usual MO:

• Source code: use source control such as svn or git. This means that you will usually have: dev, deploy and repository backups for code (specially in a drsc).
• Database: this also depends on usage, but usually:
  • Have a dump_database.py management command that will introspect settings and for each db will output the correct db dump command (taking into consideration the db type and also the database name).
  • Have a cron job on another server that connects through ssh to the application server, executes the dump db management command, tars the sql file with the db name + timestamp as the file name and uploads it to another server (amazon's s3 in my case).
• Media file: e.g. user uploads. Keep a cron job on another server that can ssh into the application server and calls rsync to another server.

The thing to keep in mind though, it what is the intended purpose of the backup. If it's accidental (be it disk failure, bug or sql injection) data loss or simply restoring, you can keep those cron jobs on the same server.

If you also want to be safe in case the server is compromised, you cannot keep the remote backup credentials (sshkeys, amazon secret etc) on the application server! Or else an attacker will gain access to the backup server.

I have a fairly complex "product" I'm getting ready to build using Django. I'm going to avoid using the terms "project" and "application" in this context, because I'm not clear on their specific meaning in Django.

Projects can have many apps. Apps can be shared among many projects. Fine.

I'm not reinventing the blog or forum - I don't see any portion of my product being reusable in any context. Intuitively, I would call this one "application." Do I then do all my work in a single "app" folder?

If so... in terms of Django's project.app namespace, my inclination is to use myproduct.myproduct, but of course this isn't allowed (but the application I'm building is my project, and my project is an application!). I'm therefore lead to believe that perhaps I'm supposed to approach Django by building one app per "significant" model, but I don't know where to draw the boundaries in my schema to separate it into apps - I have a lot of models with relatively complex relationships.

I'm hoping there's a common solution to this...

What is to stop you using myproduct.myproduct? What you need to achieve that roughly consists of doing this:

django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py

and so on. Would it help if I said views.py doesn't have to be called views.py? Provided you can name, on the python path, a function (usually package.package.views.function_name) it will get handled. Simple as that. All this "project"/"app" stuff is just python packages.

Now, how are you supposed to do it? Or rather, how might I do it? Well, if you create a significant piece of reusable functionality, like say a markup editor, that's when you create a "top level app" which might contain widgets.py, fields.py, context_processors.py etc - all things you might want to import.

Similarly, if you can create something like a blog in a format that is pretty generic across installs, you can wrap it up in an app, with its own template, static content folder etc, and configure an instance of a django project to use that app's content.

There are no hard and fast rules saying you must do this, but it is one of the goals of the framework. The fact that everything, templates included, allows you to include from some common base means your blog should fit snugly into any other setup, simply by looking after its own part.

However, to address your actual concern, yes, nothing says you can't work with the top level project folder. That's what apps do and you can do it if you really want to. I tend not to, however, for several reasons:

• Django's default setup doesn't do it.
• Often, I want to create a main app, so I create one, usually called website. However, at a later date I might want to develop original functionality just for this site. With a view to making it removable (whether or not I ever do) I tend to then create a separate directory. This also means I can drop said functionality just by unlinking that package from the config and removing the folder, rather than a complex delete the right urls from a global urls.py folder.
• Very often, even when I want to make something independent, it needs somewhere to live whilst I look after it / make it independent. Basically the above case, but for stuff I do intend to make generic.
• My top level folder often contains a few other things, including but not limited to wsgi scripts, sql scripts etc.
• django's management extensions rely on subdirectories. So it makes sense to name packages appropriately.

In short, the reason there is a convention is the same as any other convention - it helps when it comes to others working with your project. If I see fields.py I immediately expect code in it to subclass django's field, whereas if I see inputtypes.py I might not be so clear on what that means without looking at it.

I'm building web app that needs to communicate with another application using socket connections. This is new territory for me, so want to be sure that sockets are different than websockets. It seems like they're only conceptually similar.

Asking because initially I'd planned on using Django as the foundation for my project, but in the SO post I linked to above it's made very clear that websockets aren't possible (or at least not reliable, even with something like django-websockets) using the preferred Django setup (Apache with mod_wsgi). Yet I've found other posts that casually import Python's socket module for something as simple as grabbing the server's hostname.

So: a) Are they really different?
And b) Is there any reason not to use Django for a project that relies on establish socket connections with an outside server?

To answer your questions.

1. Even though they achieve (in general) similar things, yes, they are really different. WebSockets only run from browsers connecting to Application Server over a protocol similar to HTTP that runs over TCP/IP. So they are primarily for Web Applications that require a permanent connection to its server. On the other hand, plain sockets are more powerful and generic. They run over TCP/IP but they are not restricted to browsers or HTTP protocol. They could be used to implement any kind of communication.
2. No. There is no reason.

Hello Everyone,

I am about to get my hands dirty on building a application for one of the trading company entirely on python. I have experimented with django and flask. Here are few of the things i have come up

• Django is far too easy to develop an application but i feel that the ORM is limiting me in several ways
• I was very impressed with flask and how we can combine it with Jinja, SQLalchemy and Twisted but it lacks a lots of documentation and support like Django has (Seriously Django documentation is totally awesome)

So i am kinda confused as what shall i do. Should i go with Django or Flask + Werzeug

Thank You in Advance

I've used Werkzeug with Jinja and SQLAlchemy for two years and can only recommend these three libraries. Werkzeug might be a little harder to learn than Django at first but the docs are actually extensive and well written. The included debugger is extremely useful.

Unlike the Django ORM, SQLAlchemy won't get in your way. The programmatic SQL generation has very few limitations, with or without the ORM, and in the very rare cases where you need it, raw SQL is available without abandonning the benefits of wrapped query results, transaction management, connection pooling, etc.

As for Jinja, it is very similar to Django's template language, only without the limitations (you won't have to write template tags).

I haven't had the chance to try Flask yet but it's likely to be the best way to start a new project based on Werkzeug and Jinja.

Greetings,

I am curious to see how can we explain Django framework to non-programmer folks, especially clients.

• What makes Django better(or atleast a challenger) over other technologies such as Php, .Net etc.

• How can clients directly benefit from it? ( Maybe less spendings due to faster development?)

• What success stories can be told ? I know some such as NASA, Disqus

Regards

What makes Django better(or atleast a challenger) over other technologies such as Php, .Net etc.

I'm a .NET developer by day and Django developer by Night. The Advantages of Django that I could think of:

1. Django is Python, Google uses Python.
2. Django is equipped with Auto Admin Tool.
3. Django is very easy to build SEO Friendly site.
4. Django is very fast to build because it is a dynamic language.
5. Django is an open source and has very detailed/easy to follow documentations.
6. Django is scalable.

How can clients directly benefit from it?

The client can pay less but get more. The developers get paid to do more fancy, fun and innovate stuff instead of focus on debugging and fixing the code.

What success stories can be told ?

I did the quick search for "Why Django?" and here is what I get: http://www.slideshare.net/idangazit/why-django-3000105

I'm moving to Django 1.3 and find this separation of media and static files a bit confusing. Here is how default settings.py looks like:

# Absolute filesystem path to the directory that will hold user-uploaded files.
# Example: "/home/media/media.lawrence.com/media/"
MEDIA_ROOT = ''

# URL that handles the media served from MEDIA_ROOT. Make sure to use a
# trailing slash if there is a path component (optional in other cases).
# Examples: "http://media.lawrence.com/media/", "http://example.com/media/"
MEDIA_URL = ''

# Absolute path to the directory that holds static files.
# Example: "/home/media/media.lawrence.com/static/"
STATIC_ROOT = ''

# URL that handles the static files served from STATIC_ROOT.
# Example: "http://media.lawrence.com/static/"
STATIC_URL = '/static/'

What should I put into MEDIA_ROOT and a STATIC_ROOT? Should those be separate directories? What is the difference?

Static files are are meant for js/images etc, but media files is for user-uploaded content.

I'm trying to simply the deployment of our application and more easily manage the versions of libraries and frameworks that we depend on.

Does storing Django in our VCS make sense? This would ideally make it easier for me to streamline deployment and I can manage any model changes that Django makes to the built-in apps (django.contrib.auth, django.contrib.sites, etc.) using South.

Are there reasons why I shouldn't do this? What do you do for your apps?

I would absolutely store everything in your VCS. Want to update Django? Want to add a plugin? Synchronising this across a few developers and different environments could be a nightmare. Nevermind having to debug this if the versions go out of sync. What happens if you have multiple django apps that you need to work on and they're different versions?

You might want to take a look at the following two articles:

• A primer on virtualenv
• Tools of the Modern Python Hacker: Virtualenv, Fabric and Pip

I store everything from the directory that virtualenv creates in SVN. My deployment script basically consists of the following:

• Checkout (only initially, and then update) project to folder on server
• rsync to directory that Apache serves files out of (excluding .svn folders)
• Set database passwords and permissions for that environment
• Restart passenger
• Write out revision number to text file from working copy to deployment directory (could come in handy later!)

Guys!! I'm really enthusiastic in learning django and learnt a bit on Django-1.2 but then I installed 1.3 version which is ok till I run the server using the command "python manage.py runserver". It's giving a huge error. I can't figure out a way to solve this. And error is given as :

Traceback (most recent call last):    

  File "manage.py", line 11, in <module>    
    execute_manager(settings)    
  File "/usr/local/lib/python2.6/dist-packages/django/core/management/__init__.py", line 438, in execute_manager    
    utility.execute()    
  File "/usr/local/lib/python2.6/dist-packages/django/core/management/__init__.py", line 379, in execute  
    self.fetch_command(subcommand).run_from_argv(self.argv)  
  File "/usr/local/lib/python 2.6/dist-packages/django/core/management/__init__.py", line 261, in fetch_command   
    klass = load_command_class(app_name, subcommand)    
  File "/usr/local/lib/python2.6/dist-packages/django/core/management/__init__.py", line   67, in load_command_class    
    module = import_module('%s.management.commands.%s' % (app_name, name))    
  File "/usr/local/lib/python2.6/dist-packages/django/utils/importlib.py", line 35, in   import_module    
    __import__(name)    
  File "/usr/local/lib/python2.6/dist-packages/django/core/management/commands    /runserver.py", line 8, in <module>    
    from django.core.handlers.wsgi import WSGIHandler  
  File "/usr/local/lib/python2.6/dist-packages/django/core/handlers/wsgi.py", line 11, in <module>    
    from django.core import signals   
  File "/usr/local/lib/python2.6/dist-packages/django/core/signals.py", line 1, in <module>
    from django.dispatch import Signal   
  File "/usr/local/lib/python2.6/dist-packages/django/dispatch/__init__.py", line 9, in <module>    
    from django.dispatch.dispatcher import Signal, receiver    
ImportError: cannot import name receiver    

To avoid problems like that in the future, use virtualenv

I'm running celeryd as a daemon, but I sometimes have trouble stopping it gracefully. When I send the TERM signal and there are items in the queue (in this case service celeryd stop) celeryd will stop taking new jobs, and shut down all the worker processes. The parent process, however, won't shut down.

I've just ran into a scenario where I had celeryd running on two separate worker machines: A and B. With about 1000 messages on the RabbitMQ server, I shut down A, and experienced the situation I've explained above. B continued to work, but then stalled with about 40 messages left on the server. I was however, able to stop B correctly.

I restarted B, to see if it would take the 40 items off the queue, but it would not. Next, I hard killed A, after which B grabbed and completed the tasks.

My conclusions is that the parent process has reserved the 40 items from our RabbitMQ server for its children. It will reap the children correctly, but will not release the items back to RabbitMQ unless I manually kill it.

Has anyone experienced something similar?

I'm running Celery 2.2.2

I believe this is related to:

https://github.com/ask/celery/issues#issue/264

Setting

CELERY_DISABLE_RATE_LIMITS = False

in your settings.py file should work.

I could use some help complying with Django's csrf protection mechanism via my AJAX post. I've followed the directions here:

http://docs.djangoproject.com/en/dev/ref/contrib/csrf/

I've copied the AJAX sample code they have on that page exactly:

http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax

I put an alert printing the contents of getCookie('csrftoken') before the xhr.setRequestHeader call and it is indeed populated with some data. I'm not sure how to verify that the token is correct, but I'm encouraged that it's finding and sending something.

But django is still rejecting my AJAX post.

Here's my Javascript:

$.post("/memorize/", data, function (result) {
    if (result != "failure") {
        get_random_card();
    }
    else {
        alert("Failed to save card data.");
    }
});

Here's the error I'm seeing from Django:

[23/Feb/2011 22:08:29] "POST /memorize/ HTTP/1.1" 403 2332

I'm sure I'm missing something, and maybe it's simple, but I don't know what it is. I've searched around SO and saw some information about turning off the CSRF check for my view via the csrf_exempt decorator, but I find that unappealing. I've tried that out and it works, but I'd rather get my POST to work the way Django was designed to expect it, if possible.

Just in case it's helpful, here's the gist of what my view is doing:

def myview(request):

    profile = request.user.profile

    if request.method == 'POST':
        """
        Process the post...
        """
        return HttpResponseRedirect('/memorize/')
    else: # request.method == 'GET'

        ajax = request.GET.has_key('ajax')

        """
        Some irrelevent code...
        """

        if ajax:
            response = HttpResponse()
            profile.get_stack_json(response)
            return response
        else:
            """
            Get data to send along with the content of the page.
            """

        return render_to_response('memorize/memorize.html',
                """ My data """
                context_instance=RequestContext(request))

Thanks for your replies!

Real solution

Ok, I managed to trace the problem down. It lies in the Javascript (as I suggested below) code.

What you need is this:

$.ajaxSetup({ 
     beforeSend: function(xhr, settings) {
         function getCookie(name) {
             var cookieValue = null;
             if (document.cookie && document.cookie != '') {
                 var cookies = document.cookie.split(';');
                 for (var i = 0; i < cookies.length; i++) {
                     var cookie = jQuery.trim(cookies[i]);
                     // Does this cookie string begin with the name we want?
                 if (cookie.substring(0, name.length + 1) == (name + '=')) {
                     cookieValue = decodeURIComponent(cookie.substring(name.length + 1));
                     break;
                 }
             }
         }
         return cookieValue;
         }
         if (!(/^http:.*/.test(settings.url) || /^https:.*/.test(settings.url))) {
             // Only send the token to relative URLs i.e. locally.
             xhr.setRequestHeader("X-CSRFToken", getCookie('csrftoken'));
         }
     } 
});

instead of the code posted in the official docs: http://docs.djangoproject.com/en/1.2/ref/contrib/csrf/#ajax

The working code, comes from this Django entry: http://www.djangoproject.com/weblog/2011/feb/08/security/

So the general solution is: "use ajaxSetup handler instead of ajaxSend handler". I don't know why it works. But it works for me :)

Previous post (without answer)

I'm experiencing the same problem actually.

It occurs after updating to Django 1.2.5 - there were no errors with AJAX POST requests in Django 1.2.4 (AJAX wasn't protected in any way, but it worked just fine).

Just like OP, I have tried the JavaScript snippet posted in Django documentation. I'm using jQuery 1.5. I'm also using the "django.middleware.csrf.CsrfViewMiddleware" middleware.

I tried to follow the the middleware code and I know that it fails on this:

request_csrf_token = request.META.get('HTTP_X_CSRFTOKEN', '')

and then

if request_csrf_token != csrf_token:
    return self._reject(request, REASON_BAD_TOKEN)

this "if" is true, because "request_csrf_token" is empty.

Basically it means that the header is NOT set. So is there anything wrong with this JS line:

xhr.setRequestHeader("X-CSRFToken", getCookie('csrftoken'));

?

I hope that provided details will help us in resolving the issue :)

I want lists of website to follow for Django and Python: also i follow these sites:

• http://djangoadvent.com/
• http://mail.python.org/mailman/listinfo/python-list
• http://www.djangoproject.com/weblog/
• http://bretthoerner.com/
• http://www.devshed.com/c/b/Python/

please complete list

Just head over to http://planet.python.org and http://planetdjango.org/ and be selective amongst them.