Have you ever wondered why you can’t have manage.py sqlall output your create table statements as InnoDB tables for mysql? Well I have. I always go in and update the statements by hand to add that after the fact. So I did a bit of pokeing around and figured out a hack to add in a settings flag so you can set the table type that your manage.py will use for its create table statements.

There are 2 changes you need to make. First off you need to add the following setting in your settings.py

DATABASE_TABLE_ENGINE = 'InnoDB'

the other part is an update to the django.core.management.sql file. This file is really long (even though the actual hack is short). Basically the update is adding the following code in the many_to_many_sql_for_model and sql_model_create functions.

try:
   if settings.DATABASE_TABLE_ENGINE != None:
      table_output.append('ENGINE=%s' % settings.DATABASE_TABLE_ENGINE)
except:
   pass

It’s really pretty basic but personally I find it useful. Now (here comes the disclaimer) I can’t guarantee that there isn’t already a way to do this. Despite all my digging I didn’t find it if it does exist. Also I’m sure there is a better way to add this update then going in and hacking the core script (or even if that’s playing nice and submitting an enhancement ticket which I should really read up on). On that note I would suggest not just swapping out the download version for your version. It would prob be best to just use my version as a guide to show you how to update your own sql.py so you don’t run into any file version probs. Just for the sake of clarity I’m running django svn trunk version 6898.

Edit I noticed my local django version was pretty damn old so I just updated to 7353. The hack still seems to be working fine. End Edit

You can download a copy of my hacked sql.py here: updated django.core.management.sql . As always use at your own risk and let me know what could be done better.

Edit I’m adding a svn diff as well for those of you who would rather see only the changes: download diffEnd Edit

edit:
# ericflo pointed out something that I totally forgot about… render_to_string. And he’s completely correct… It does exactly the same thing and most likely does it better… DOH! Well whatever… here is my version anyway

—————————
Here is a handy little helper I cooked up for dynamically loading dynamic content into a reusable template wrapper. It takes the path of a template and a dict of vars to populate, compiles the template and returns the resulting value as a string. You can then pass in the resulting variable into your main context. Pretty simple but very useful.

def wrap_content(template, var_dict):
    from django.template import Context, loader
    c = Context(var_dict)
    t = loader.get_template(template)
    return t.render(c)

called like so

mod = wrap_content('shared/mod_wrapper.html',{'title':'test title','content':'content test',})

So lately I’ve been working out all the kinks of running Django via pydev/eclipse so I can do more dev on my local machine. Since localy I run windows but I deploy onto Ubuntu Linux I’ve come up with a little hack that lets me conditionally load my project settings based on which environment it’s being run in. It’s pretty basic but I find it very helpful. If anyone else has any other approaches pls shout em out.

So all you have to do is create a file with all your development settings in your project folder (same folder the normal settings.py is in) and name it development_settings.py. Besides that you just have to replace the original manage.py in your project with the following manage.py. This one looks to see if your settings.py has DEBUG = True and if so loads the development.py instead.

#!/usr/bin/env python
from django.core.management import execute_manager
try:
    import settings # Assumed to be in the same directory.

    if settings.DEBUG:
        import development_settings
        startup_settings = development_settings
    else:
        startup_settings = settings

except ImportError:
    import sys
    sys.stderr.write("Error: Can't find the file 'settings.py' in the directory containing %r. It appears you've customized things.nYou'll have to run django-admin.py, passing it your settings module.n(If the file settings.py does indeed exist, it's causing an ImportError somehow.)n" % __file__)
    sys.exit(1)

if __name__ == "__main__":
    execute_manager(startup_settings)

Here is a graph I generated from trendrr.com to show how many search results google blogs returns for ruby vs python. It makes me happy on the inside to see them so neck and neck.