<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="Content-type" content="text/html; charset=utf-8"> <title>Appendix B: Model Definition Reference</title> <link rel="stylesheet" href="http://new-media.djangobook.com/yui/reset/reset-min.css" type="text/css"> <link rel="stylesheet" href="http://new-media.djangobook.com/yui/grids/grids-min.css" type="text/css"> <link rel="stylesheet" href="http://new-media.djangobook.com/djangobook.css" type="text/css"> <link href="http://new-media.djangobook.com/yui/container/assets/container.css" type="text/css" media="screen" rel="stylesheet"> <link href="http://new-media.djangobook.com/yui-ext/css/tabs.css" type="text/css" media="screen" rel="stylesheet"> <link href="http://new-media.djangobook.com/yui-ext/css/resizable.css" type="text/css" media="screen" rel="stylesheet"> </head> <body> <div id="doc" class="yui-t7"> <div id="hd"> <h1><a href="http://www.djangobook.com/">The Django Book</a></h1> <div id="global-nav"> <a class="about" href="http://www.djangobook.com/about/">About</a> | <a class="comment-help" href="http://www.djangobook.com/about/comments/">Comment help</a> | <a class="contact" href="http://www.djangobook.com/contact/">Contact us</a> | <a class="errata" href="http://www.djangobook.com/errata/">Errata</a> | <a class="buy" href="http://www.amazon.com/gp/product/1590597257?ie=UTF8&amp;tag=jacobianorg-20&amp;linkCode=as2&amp;camp=1789&amp;creative=9325&amp;creativeASIN=1590597257"> Buy the print version on Amazon.com</a> </div> <div class="nav"> <a href='../appendixA/index.html'>&laquo; previous</a> &loz; <a href="../index.html">table of contents</a> &loz; <a href='../appendixC/index.html'>next &raquo;</a> </div> </div> <div id="bd"> <div id="yui-main"> <div class="yui-b"> <h2 id="chapter-title">Appendix B: Model Definition Reference</h2> <div id="chapter-body"> <p class="cn" id="cn0">Chapter 5 explains the basics of defining models, and we use them throughout the rest of the book. There is, however, a <em>huge</em> range of model options available not covered elsewhere. This appendix explains each possible model definition option.</p> <p class="cn" id="cn1">Note that although these APIs are considered very stable, the Django developers consistently add new shortcuts and conveniences to the model definition. It&#8217;s a good idea to always check the latest documentation online at <a class="reference external" href="http://www.djangoproject.com/documentation/0.96/model-api/">http://www.djangoproject.com/documentation/0.96/model-api/</a>.</p> <div class="section" id="s-fields"> <h3 class="cn" id="cn2">Fields</h3> <p class="cn" id="cn3">The most important part of a model &#8212; and the only required part of a model &#8212; is the list of database fields it defines.</p> <div class="admonition-field-name-restrictions admonition cn admonition" id="cn4"> <p class="first admonition-title">Field Name Restrictions</p> <p>Django places only two restrictions on model field names:</p> <ol class="arabic"> <li><p class="first">A field name cannot be a Python reserved word, because that would result in a Python syntax error, for example:</p> <pre class="literal-block"> class Example(models.Model): pass = models.IntegerField() # 'pass' is a reserved word! </pre> </li> <li><p class="first">A field name cannot contain more than one underscore in a row, due to the way Django&#8217;s query lookup syntax works, for example:</p> <pre class="literal-block"> class Example(models.Model): foo__bar = models.IntegerField() # 'foo__bar' has two underscores! </pre> </li> </ol> <p>These limitations can be worked around, though, because your field name doesn&#8217;t necessarily have to match your database column name. See &#8220;db_column&#8221;, below. below.</p> <p class="last">SQL reserved words, such as <tt class="docutils literal"><span class="pre">join</span></tt>, <tt class="docutils literal"><span class="pre">where</span></tt>, or <tt class="docutils literal"><span class="pre">select</span></tt>, <em>are</em> allowed as model field names, because Django escapes all database table names and column names in every underlying SQL query. It uses the quoting syntax of your particular database engine.</p> </div> <p class="cn" id="cn5">Each field in your model should be an instance of the appropriate <tt class="docutils literal"><span class="pre">Field</span></tt> class. Django uses the field class types to determine a few things:</p> <ul class="simple"> <li class="cn" id="cn6">The database column type (e.g., <tt class="docutils literal"><span class="pre">INTEGER</span></tt>, <tt class="docutils literal"><span class="pre">VARCHAR</span></tt>).</li> <li class="cn" id="cn7">The widget to use in Django&#8217;s admin interface, if you care to use it (e.g., <tt class="docutils literal"><span class="pre">&lt;input</span> <span class="pre">type=&quot;text&quot;&gt;</span></tt>, <tt class="docutils literal"><span class="pre">&lt;select&gt;</span></tt>).</li> <li class="cn" id="cn8">The minimal validation requirements, which are used in Django&#8217;s admin interface.</li> </ul> <p class="cn" id="cn9">A complete list of field classes follows, sorted alphabetically. Note that relationship fields (<tt class="docutils literal"><span class="pre">ForeignKey</span></tt>, etc.) are handled in the next section.</p> <div class="section" id="s-autofield"> <h4 class="cn" id="cn10">AutoField</h4> <p class="cn" id="cn11">An <tt class="docutils literal"><span class="pre">IntegerField</span></tt> that automatically increments according to available IDs. You usually won&#8217;t need to use this directly; a primary key field will automatically be added to your model if you don&#8217;t specify otherwise.</p> </div> <div class="section" id="s-booleanfield"> <h4 class="cn" id="cn12">BooleanField</h4> <p class="cn" id="cn13">A true/false field.</p> </div> <div class="section" id="s-charfield"> <h4 class="cn" id="cn14">CharField</h4> <p class="cn" id="cn15">A string field, for small- to large-sized strings. For large amounts of text, use <tt class="docutils literal"><span class="pre">TextField</span></tt>.</p> <p class="cn" id="cn16"><tt class="docutils literal"><span class="pre">CharField</span></tt> has an extra required argument, <tt class="docutils literal"><span class="pre">maxlength</span></tt>, which is the maximum length (in characters) of the field. This maximum length is enforced at the database level and in Django&#8217;s validation.</p> </div> <div class="section" id="s-commaseparatedintegerfield"> <h4 class="cn" id="cn17">CommaSeparatedIntegerField</h4> <p class="cn" id="cn18">A field of integers separated by commas. As in <tt class="docutils literal"><span class="pre">CharField</span></tt>, the <tt class="docutils literal"><span class="pre">maxlength</span></tt> argument is required.</p> </div> <div class="section" id="s-datefield"> <h4 class="cn" id="cn19">DateField</h4> <p class="cn" id="cn20">A date field. <tt class="docutils literal"><span class="pre">DateField</span></tt> has a few extra optional arguments, as shown in Table B-1.</p> <table class="cn docutils" id="cn21"> <caption>Table B-1. Extra DateField Options</caption> <colgroup> <col width="30%" /> <col width="70%" /> </colgroup> <thead valign="bottom"> <tr><th class="head">Argument</th> <th class="head">Description</th> </tr> </thead> <tbody valign="top"> <tr><td><tt class="docutils literal"><span class="pre">auto_now</span></tt></td> <td>Automatically sets the field to now every time the object is saved. It&#8217;s useful for &#8220;last-modified&#8221; timestamps. Note that the current date is <em>always</em> used; it&#8217;s not