Django Errors - Django Tutorials - Django Freelancer Resource on Django

This is the usual way of defining a model in a relational database, but Django doesn’t do that.

In a nutshell, a model describes your data. They’re like a blueprint: they explain what types of objects you’ll use, what fields those objects have, and how it all fits together. In Django, models definitions also contain metadata about your models that Django uses to build APIs — more on that later.

Although relational databases were first conceived of in the 1960s and have been around in some form or another for many years, the web has really taken database use to a whole new level. Almost every web site is backed by one database or another.

When done right, database-backed websites are extremely useful. Instead of the top-down style that dominates in print, databased websites let readers “choose their own adventures” as they move through the site.

The best sites take this to an extreme by providing tools that let readers sift through mountains of data they’d otherwise be unable to process. Helping developers build those tools is the primary purpose of Django. It makes sense, then, to start our discussion of Django development by focusing on how Django handles data modeling.

So we’ll end up with three apps: one for the cheeseshop packages, one for votes on packages, and one of the users. Luckily, Django provides a built-in user app that’ll take care of all that user business, so we only need to write two apps.

Why break votes out into a different package? Well, mostly because it’s a somewhat separate concept from packages: the idea of “voting” has nothing to do with the idea of tracking Python add-ons. In this beginning tutorial the division might seem a bit arbitrary since we’re not going to talk about votes at all. However, in the advanced tutorial (and in the site code you can download), you’ll see that the voting mechanism is a generic one that can apply to any model.

So these are the models we’ve got to deal with. I’ll talk more about models in just a little bit, but for now you can think of each of these as a database table.

Now that we’ve got the skeleton of a project working, we’ll start on an app. An app is just a collection of data and code that makes up some sort of logical “unit”. Typically, projects are composed of a number of apps; the cool part is that apps can be reused in multiple projects.

Typically, an app exists to solve a single problem.

Often, design of apps is iterative: you start with a single app with a bunch of code and over time refactor it into a set of smaller apps as the difference between pieces becomes more apparent. This isn’t exactly possible in just three hours, so I’ll try to summarize how I came to the design we’ll be using.