Django for the Rails Developer

Django is the most popular Python web application development framework. Many people consider it Python’s Rails. If you are an experienced Rails developer this article will help you get started with building Django apps and help map Rails concepts to Django.

What Do I Need to Get Started?

We will assume that you are an experienced developer and so spend no time in explaining the basics such as installing Django or Python. If you need help with that, please look here. We will also not focus on creating a basic app using Django. Django docs already cover that, if you need help read this article.

If you are still reading, I assume you can build a basic Django app, and you now want to map your Rails concepts to Django. Lets get started.

You Say MVC, I Say MTV

Rails is an MVC framework. You write your data interactions in app/models/model_name.rb, you write your controllers in app/controllers/controller_name.rb and you render the data using a view from app/views/. Django is a MVC framework, but it differs from standard MVC terminology.

In Django, the controllers become the views, and views become the template.

So in

Rails: Controller is the ruby code which decides what data gets shown.
Django: View is the Python code which determines what data gets shown.

and

Rails: Views decide how the data is rendered. This can be erb or haml code.
Django: Templates decide how the data is rendered. This is html with Django specific tags.

Django calls this the MTV architecture and has more details about this in their faqs.

At Least the Models Are the Same?

You would hope so, but then life wouldn’t be so much fun. In Rails db/schema.rb is the authoritative source for your database schema. To add a new model or to make changes to your existing model, you create and run a migration which changes the schema. The schema.rb file is auto-generated from the current state of the database. You would generally not edit the schema.rb manually. You keep your model validations and business logic in app/models/model_name.rb.

In Django, the authoritative source of thie database schema is app_name/models.py. To create a new table, you edit your models.py and then run either the syncdb or the migrate command. You will need the very popular south app for migrate command.

In Rails, the DB is the authoritative source and schema.rb is autogenerated from it. In Django, models.py is the authoritative source and DB is synced from it.

Not in a Complicated Relationship

In Rails you would model foreign key relationships via has_many, belongs_to, has_one, has_and_belongs_to_many. In Django you specify them as attributes on your models as models.ForeignKey, models.OneToOneField, models.ManyToManyField. In Django you only need to specify one side of the relationship, the other Model object will automatically get the related methods. Here is the mapping.

belongs_to -> ForeignKey
has_many -> (Not needed, as Django automatically add these after getting a ForeignKey)
has_one -> OneToOneField (Only needed to specify on one of the models)
has_and_belong_to_many -> ManyToManyField (Only needed to specify on one of the models)

Model Objects and Querysets.

Once you have defined the model, they have many equivalent methods. Lets say you have a User model available in both Rails and Django.

Rails: User.create(..)
Django: User.objects.create(..)

Saving a model after making some changes

Rails: user.save!
Django: user.save()

Django queryset and Rails AR relations are also pretty much equivalent, offering similar methods.

Rails: Model.find(10)
Django: Model.objects.get(id=10)

Rails: Model.where(..conditions)
Django: Model.objects.filter(..conditions)

Rails: Model.order(“createdat”)
Django: Model.objects.orderby(“created_at”)

The big difference is that, in Django, the methods are on a manager. (Generally called objects), instead of the Model class itself.

Routing and Config

In Rails, the config files are in config/* and each environment, such as development, test, and production, get their own config file. In Django most of the configuration is in settings.py. Rails puts routing in config/routes.rb. Django puts rouring/dispatch in urls.py and is regex based.

Templating and Views

Rails views are ERB or haml files. Django templates have template tags, which correspond to Rails helpers and the Django {% include ..%} template tag corresponds to Rails partials.

Some More Mappings.

Development Server

Rails: rails server
Django: python manage.py server

Development Console

Rails: rails console
Django: python manage.py shell

Database Migrations

Rails: rake db:create && rake db:migrate
Django: python manage.py syncdb && python manage.py migrate

Tasks

Django comes with a manage.py script which performs many actions available on rails/rake.

Routing

Rails: config/routes.rb
Django: urls.py

Callbacks

Rails: callbacks (such as beforesave)
Django: signals (Such as presave) or overriding lifecycle methods such as .save

Observers

Rails: observers
Django: signals

Custom Tasks

Rails: custom rake tasks
Django: Custom management commands

What Next?

This article should give you enough pointers to apply your Rails knowledge to start working on Django. This article is specifically not a Rails vs Django post. Rails and Django are both amazing frameworks, and knowing Django can give you valuable insights and ideas to work better with Rails even if you never use Django in production.

I’d love to hear your take on the similarities and differences between Rails and Django in the comments section. Thanks for reading!

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Pavel

    The only question is why would anyone who knows Rails use Django?

    • zedtux

      Because your company ask it. :-D

  • http://birdhouse.org/blog Scot Hacker

    Correction: Under Development Server:

    Django: python manage.py server
    should be:
    Django: python manage.py runserver
    or just
    ./manage.py server

    (I alias this to simply “rundj”)

  • http://birdhouse.org/blog Scot Hacker

    Pavel – See the What’s Next section above for the answer to your question.

  • http://blog.glaucocustodio.com Glauco

    Great post! I have used Django for some time and now I am going to Rails, but it does not mean that Rails is better than Django, it just means that I prefer Rails way to do things instead Django (cause I come from CakePHP, it seems Rails).
    Django is a great tool and I think that development with him is faster than Rails, however it is a long point to discuss.

  • http://www.trivial.ly Nicholas Johnson

    I used Django on a project a while back. I gave it a really good go, and it seemed perfectly capable, but I have to say it was not a particularly fun experience when compared to Rails.

    * Rails lets you make anything you can dream of.
    * Django lets you make a CMS.

    Django is fine, as long as your cool with that.

    • http://twitter.com/charlesroper Charles Roper

      @Nicholas Johnson, I know where you’re coming from with the Django only does CMSs sentiment because it did indeed grow out of a newspaper CMS project and has a CMS flavour, especially for the beginner (which is by design). But the keyword there is “grow” because it blossomed into something far more capable and it can indeed be used to build “anything you can dream of.” As long it’s a website, mobile app or related digital product. ;-)

      Here are some great examples: http://stackoverflow.com/questions/1906795/what-are-some-famous-websites-built-in-django

  • http://www.trivial.ly Nicholas Johnson

    I did enjoy Python though, it seemed like a more grown up version of Ruby. Less magic, more workmanlike.

  • http://programmingbeans.wordpress.com Mahmoud

    Also, using User.objects.create(..) is unnecessary, all you need is to create a new User instance like this:

    User(..)

    and then save it like the article says.

  • http://blog.jupo.org Stephen McDonald

    Wrote the reverse a while back, Rails quickstart for Djangonauts: http://blog.jupo.org/2011/07/30/rails-quick-start-for-djangonauts/