==========
>>!
Django FAQ
<<!
>>!!
쟁고 자주묻는 질문과 답변
<<!!
==========

>>!
General questions
<<!
>>!!
일반적인 질문
<<!!
=================

>>!
Why does this project exist?
<<!
>>!!
이 프로젝트는 왜 있는 겁니까?
<<!!
----------------------------

>>!
Django grew from a very practical need: World Online, a newspaper Web
operation, is responsible for building intensive Web applications on journalism
deadlines. In the fast-paced newsroom, World Online often has only a matter of
hours to take a complicated Web application from concept to public launch.

At the same time, the World Online Web developers have consistently been
perfectionists when it comes to following best practices of Web development.

In fall 2003, the World Online developers (Adrian Holovaty and Simon Willison)
ditched PHP and began using Python to develop its Web sites. As they built
intensive, richly interactive sites such as Lawrence.com, they began to extract
a generic Web development framework that let them build Web applications more
and more quickly. They tweaked this framework constantly, adding improvements
over two years.

In summer 2005, World Online decided to open-source the resulting software,
Django. Django would not be possible without a whole host of open-source
projects -- `Apache`_, `Python`_, and `PostgreSQL`_ to name a few -- and we're
thrilled to be able to give something back to the open-source community.
<<!
>>!!
쟁고는 실용적인 이유에서 성장했습니다.: 뉴스 사이트인 월드 온라인(World
Online)은 편집 마감시간에 대응할 수 있는 웹 어플리케이션이 필요했습니다.월드
온라인에서는 빈번하게 아이디어에서부터 바로 운영할 수 있는 복잡한 웹
어플리케이션을 작성하는 데 불과 몇시간이 주어지기도 합니다.

그러한 때에, 월드 온라인의 웹 개발자들은 웹 개발에서 최고의 경험을 쌓으면서 점차
완벽주의자들이 되어갔습니다.

2003년 가을, 월드 온라인의 개발자들(애드리언 홀로배티와 싸이먼 윌슨)은 PHP를
묻어버리고 파이썬으로 웹 사이트를 개발하기 시작했습니다. Lawrence.com과 같은
비중있고 풍부한 사용자 경험을 강조하는 사이트를 구축하면서 이들은 웹
어플리케이션을 조금더 빨리 개발할 수 있는 웹 개발 프레임워크의 핵심을 만들어가기
시작합니다. 이들은 이 프레임워크를 계속 수정해가면서 2년 넘게 개선을
거듭해왔습니다.

2005년 여름, 월드 온라인은 이 프레임워크를 쟁고라는 이름의 오픈소스 소프트웨어로
공개하기로 결정합니다. 쟁고는 `아파치`_, `파이썬`_, and `PostgreSQL`_ 등과 같은
오픈소스 프로젝트의 도움 없이는 불가능했습니다. 우리는 오픈소스 공동체에 무언가
돌려줄 수 있다는 점에서 매우 흐뭇하게 생각하고 있습니다.
<<!!

>>!
.. _Apache: http://httpd.apache.org/
.. _Python: http://www.python.org/
.. _PostgreSQL: http://www.postgresql.org/
<<!
>>!!
.. _아파치: http://httpd.apache.org/
.. _파이썬: http://www.python.org/
.. _PostgreSQL: http://www.postgresql.org/
<<!!

>>!
What does "Django" mean, and how do you pronounce it?
<<!
>>!!
"쟁고"는 무엇을 뜻하나요? 발음은요?
<<!!
-----------------------------------------------------

>>!
Django is named after `Django Reinhardt`_, a gypsy jazz guitarist from the 1930s
to early 1950s. To this day, he's considered one of the best guitarists of all time.

Listen to his music. You'll like it.

Django is pronounced **JANG**-oh. Rhymes with FANG-oh. The "D" is silent.

We've also recorded an `audio clip of the pronunciation`_.
<<!
>>!!
쟁고는 `쟁고 라인하르트 Django Reinhardt`의 이름을 따라서 지어졌습니다. 쟁고
라인하르트는 1930년대서부터 50년대까지 활동한 집시 재즈 기타연주자입니다. 오늘날
그는 전시대를 통틀어서 가장 뛰어난 기타연주자로 평가되고 있습니다.

그의 노래를 들어보세요. 훌륭할 겁니다.

쟁고는 **쟁**고라고 발음합니다. "D"는 소리내지 않습닏.

미리 녹음한 `발음을 녹음한 소리`_를 들어보세요.
<<!!

>>!
.. _쟁고 라인하르트는: http://en.wikipedia.org/wiki/Django_Reinhardt
.. _발음을 녹음한 소리: http://red-bean.com/~adrian/django_pronunciation.mp3

>>!
Is Django stable?
<<!
>>!!
쟁고는 안정적인가요?
<<!!
-----------------

>>!
Yes. World Online has been using Django for more than three years. Sites built
on Django have weathered traffic spikes of over one million hits an hour and a
number of Slashdottings. Yes, it's quite stable.
<<!
>>!!
물론입니다. 월드 온라인은 3년 이상 쟁고를 사용해오고 있습니다. 쟁고로 구축된
사이트들은 시간당 조회수 백만개 이상의 트래픽 집중을 너끈히 처리하고 있습니다.
예, 매우 안정적입니다.
<<!!

>>!
Does Django scale?
<<!
>>!!
쟁고는 쉽게 확장될 수 있나요?
<<!!
------------------

>>!
Yes. Compared to development time, hardware is cheap, and so Django is
designed to take advantage of as much hardware as you can throw at it.

Django uses a "shared-nothing" architecture, which means you can add hardware
at any level -- database servers, caching servers or Web/application servers.

The framework cleanly separates components such as its database layer and
application layer. And it ships with a simple-yet-powerful `cache framework`_.
<<!
>>!!
예, 그렇습니다. 쟁고는 "얽혀있지 않은" 구조를 사용합니다. 이 말은 어떤
단계에서도 하드웨어를 추가할 수 있다는 뜻입니다. -- 데이터베이스 서버, 캐싱 서버
혹은 웹 어플리케이션 서버들.

프레임워크는 데이터베이스 계층과 어플리케이션 계층과 같은 구조와 깨끗하게
분리됩니다. 그래서 간단하지만-강력한 `캐싱 프레임워크`를 지니고 있습니다.
<<!!

>>!
.. _`cache framework`: ../cache/
<<!
>>!!
.. _`캐싱 프레임워크`: ../cache/
<<!!

>>!
Who's behind this?
<<!
>>!!
쟁고 뒤에는 누가 있지요?
<<!!
------------------

>>!
Django was developed at `World Online`_, the Web department of a newspaper in
Lawrence, Kansas, USA.
<<!
>>!!
쟁고는 `월드 온라인`_의 웹 개발팀에서 개발되었습니다.  월드 온라인은 미국
캔사스주 로렌스에 있습니다.
<<!!

>>!
`Adrian Holovaty`_
    Adrian is a Web developer with a background in journalism. He was lead
    developer at World Online for 2.5 years, during which time Django was
    developed and implemented on World Online's sites. Now he works for
    washingtonpost.com building rich, database-backed information sites, and
    continues to oversee Django development. He likes playing guitar (Django
    Reinhardt style) and hacking on side projects such as `chicagocrime.org`_.
    He lives in Chicago.

    On IRC, Adrian goes by ``adrian_h``.
<<!
>>!!
`애드리언 홀로배티`_
    애드리언은 저널리스트 경험을 가지고 있는 웹 개발자입니다. 그는 월드
	 온라인에서 쟁고가 개발되고 월드 온라인에 구축되던 2년 반동안 지도적인
	 개발자였습니다. 지금은 워싱턴포스트에서 일하고 있습니다. 거기서 풍부하고
	 데이터베이스에 기반한 사이트를 구축하면서 계속 쟁고 개발에 전념하고
	 있습니다. 기타를 즐기고(쟁고 라인하르트처럼?) `chicagocrime.org`_같은
	 프로젝트를 해킹하기도 합니다. 시카고에서 살고 있습니다.
<<!!

>>!
`Jacob Kaplan-Moss`_
    Jacob is a whipper-snapper from California who spends equal time coding and
    cooking. He's lead developer at World Online and actively hacks on various
    cool side projects. He's contributed to the Python-ObjC bindings and was
    the first guy to figure out how to write Tivo apps in Python. Lately he's
    been messing with Python on the PSP. He lives in Lawrence, Kansas.

    On IRC, Jacob goes by ``jacobkm``.
<<!
>>!!
<<!!

>>!
`Simon Willison`_
    Simon is a well-respected Web developer from England. He had a one-year
    internship at World Online, during which time he and Adrian developed
    Django from scratch. The most enthusiastic Brit you'll ever meet, he's
    passionate about best practices in Web development and has maintained a
    well-read Web-development blog for years at http://simon.incutio.com.
    He works for Yahoo UK, where he managed to score the title "Hacker Liason."
    He lives in London.

    On IRC, Simon goes by ``SimonW``.
<<!
>>!!
<<!!

>>!
`Wilson Miner`_
    Wilson's design-fu makes us all look like rock stars. By day, he's an
    interactive designer for `Apple`_. Don't ask him what he's working on, or
    he'll have to kill you. He lives in San Francisco.

    On IRC, Wilson goes by ``wilsonian``.
<<!
>>!!
<<!!

>>!
.. _`World Online`: http://code.djangoproject.com/wiki/WorldOnline
.. _`Adrian Holovaty`: http://www.holovaty.com/
.. _`washingtonpost.com`: http://www.washingtonpost.com/
.. _`chicagocrime.org`: http://www.chicagocrime.org/
.. _`Simon Willison`: http://simon.incutio.com/
.. _`simon.incutio.com`: http://simon.incutio.com/
.. _`Jacob Kaplan-Moss`: http://www.jacobian.org/
.. _`Wilson Miner`: http://www.wilsonminer.com/
.. _`Apple`: http://www.apple.com/
<<!
>>!!
<<!!

>>!
Which sites use Django?
<<!
>>!!
<<!!
-----------------------

>>!
The Django wiki features a consistently growing `list of Django-powered sites`_.
Feel free to add your Django-powered site to the list.
<<!
>>!!
<<!!

>>!
.. _list of Django-powered sites: http://code.djangoproject.com/wiki/DjangoPoweredSites
<<!
>>!!
<<!!

>>!
Django appears to be a MVC framework, but you call the Controller the "view", and the View the "template". How come you don't use the standard names?
<<!
>>!!
<<!!
-----------------------------------------------------------------------------------------------------------------------------------------------------

>>!
Well, the standard names are debatable.

In our interpretation of MVC, the "view" describes the data that gets presented
to the user. It's not necessarily *how* the data *looks*, but *which* data is
presented. The view describes *which data you see*, not *how you see it.* It's
a subtle distinction.

So, in our case, a "view" is the Python callback function for a particular URL,
because that callback function describes which data is presented.

Furthermore, it's sensible to separate content from presentation -- which is
where templates come in. In Django, a "view" describes which data is presented,
but a view normally delegates to a template, which describes *how* the data is
presented.

Where does the "controller" fit in, then? In Django's case, it's probably the
framework itself: the machinery that sends a request to the appropriate view,
according to the Django URL configuration.

If you're hungry for acronyms, you might say that Django is a "MTV" framework
-- that is, "model", "template", and "view." That breakdown makes much more
sense.

At the end of the day, of course, it comes down to getting stuff done. And,
regardless of how things are named, Django gets stuff done in a way that's most
logical to us.
<<!
>>!!
<<!!

>>!
<Framework X> does <feature Y> -- why doesn't Django?
<<!
>>!!
<<!!
-----------------------------------------------------

>>!
We're well aware that there are other awesome Web frameworks out there, and
we're not averse to borrowing ideas where appropriate. However, Django was
developed precisely because we were unhappy with the status quo, so please be
aware that "because <Framework X>" does it is not going to be sufficient reason
to add a given feature to Django.

Why did you write all of Django from scratch, instead of using other Python libraries?
<<!
>>!!
<<!!
--------------------------------------------------------------------------------------

>>!
When Django was originally written a couple of years ago, Adrian and Simon
spent quite a bit of time exploring the various Python Web frameworks
available.

In our opinion, none of them were completely up to snuff.

We're picky. You might even call us perfectionists. (With deadlines.)

Over time, we stumbled across open-source libraries that did things we'd
already implemented. It was reassuring to see other people solving similar
problems in similar ways, but it was too late to integrate outside code: We'd
already written, tested and implemented our own framework bits in several
production settings -- and our own code met our needs delightfully.

In most cases, however, we found that existing frameworks/tools inevitably had
some sort of fundamental, fatal flaw that made us squeamish. No tool fit our
philosophies 100%.

Like we said: We're picky.

We've documented our philosophies on the `design philosophies page`_.
<<!
>>!!
<<!!

>>!
.. _design philosophies page: ../design_philosophies/
<<!
>>!!
<<!!

>>!
Do you have any of those nifty "screencast" things?
<<!
>>!!
<<!!
---------------------------------------------------

>>!
You can bet your bottom they're on the way. But, since we're still hammering
out a few points, we want to make sure they reflect the final state of things
at Django 1.0, not some intermediary step. In other words, we don't want to
spend a lot of energy creating screencasts yet, because Django APIs will shift.
<<!
>>!!
<<!!

>>!
Is Django a content-management-system (CMS)?
<<!
>>!!
<<!!
--------------------------------------------

>>!
No, Django is not a CMS, or any sort of "turnkey product" in and of itself.
It's a Web framework; it's a programming tool that lets you build Web sites.

For example, it doesn't make much sense to compare Django to something like
Drupal_, because Django is something you use to *create* things like Drupal.

Of course, Django's automatic admin site is fantastic and timesaving -- but
the admin site is one module of Django the framework. Furthermore, although
Django has special conveniences for building "CMS-y" apps, that doesn't mean
it's not just as appropriate for building "non-CMS-y" apps (whatever that
means!).
<<!
>>!!
<<!!

>>!
.. _Drupal: http://drupal.org/
<<!
>>!!
<<!!

>>!
When will you release Django 1.0?
<<!
>>!!
<<!!
---------------------------------

>>!
Short answer: When we're comfortable with Django's APIs, have added all
features that we feel are necessary to earn a "1.0" status, and are ready to
begin maintaining backwards compatibility. 

The merging of Django's `magic-removal branch`_ went a long way toward Django
1.0.

Of course, you should note that `quite a few production sites`_ use Django in
its current status. Don't let the lack of a 1.0 turn you off.
<<!
>>!!
<<!!

>>!
.. _magic-removal branch: http://code.djangoproject.com/wiki/RemovingTheMagic
.. _quite a few production sites: http://code.djangoproject.com/wiki/DjangoPoweredSites
<<!
>>!!
<<!!

>>!
How can I download the Django documentation to read it offline?
<<!
>>!!
<<!!
---------------------------------------------------------------

>>!
The Django docs are available in the ``docs`` directory of each Django tarball
release. These docs are in ReST (ReStructured Text) format, and each text file
corresponds to a Web page on the official Django site.

Because the documentation is `stored in revision control`_, you can browse
documentation changes just like you can browse code changes.

Technically, the docs on Django's site are generated from the latest development
versions of those ReST documents, so the docs on the Django site may offer more
information than the docs that come with the latest Django release.
<<!
>>!!
<<!!

>>!
.. _stored in revision control: http://code.djangoproject.com/browser/django/trunk/docs
<<!
>>!!
<<!!

>>!
Where can I find Django developers for hire?
<<!
>>!!
<<!!
--------------------------------------------

>>!
Consult our `developers for hire page`_ for a list of Django developers who
would be happy to help you.

You might also be interested in posting a job to http://www.gypsyjobs.com/ .
<<!
>>!!
<<!!

>>!
.. _developers for hire page: http://code.djangoproject.com/wiki/DevelopersForHire
<<!
>>!!
<<!!

>>!
Installation questions
<<!
>>!!
<<!!
======================

>>!
How do I get started?
<<!
>>!!
<<!!
---------------------

>>!
    #. `Download the code`_.
    #. Install Django (read the `installation guide`_).
    #. Walk through the tutorial_.
    #. Check out the rest of the documentation_, and `ask questions`_ if you
       run into trouble.
<<!
>>!!
<<!!

>>!
.. _`Download the code`: http://www.djangoproject.com/download/
.. _`installation guide`: ../install/
.. _tutorial:  ../tutorial01/
.. _documentation: ../
.. _ask questions: http://www.djangoproject.com/community/
<<!
>>!!
<<!!

>>!
How do I fix the "install a later version of setuptools" error?
<<!
>>!!
<<!!
---------------------------------------------------------------

>>!
Just run the ``ez_setup.py`` script in the Django distribution.
<<!
>>!!
<<!!

>>!
What are Django's prerequisites?
<<!
>>!!
<<!!
--------------------------------

>>!
Django requires Python_ 2.3 or later. No other Python libraries are required
for basic Django usage.

For a development environment -- if you just want to experiment with Django --
you don't need to have a separate Web server installed; Django comes with its
own lightweight development server. For a production environment, we recommend
`Apache 2`_ and mod_python_, although Django follows the WSGI_ spec, which
means it can run on a variety of server platforms.

If you want to use Django with a database, which is probably the case, you'll
also need a database engine. PostgreSQL_ is recommended, because we're
PostgreSQL fans, and MySQL_, `SQLite 3`_, and Oracle_ are also supported.
<<!
>>!!
<<!!

>>!
.. _Python: http://www.python.org/
.. _Apache 2: http://httpd.apache.org/
.. _mod_python: http://www.modpython.org/
.. _WSGI: http://www.python.org/peps/pep-0333.html
.. _PostgreSQL: http://www.postgresql.org/
.. _MySQL: http://www.mysql.com/
.. _`SQLite 3`: http://www.sqlite.org/
.. _Oracle: http://www.oracle.com/
<<!
>>!!
<<!!

>>!
Do I lose anything by using Python 2.3 versus newer Python versions, such as Python 2.5?
<<!
>>!!
<<!!
----------------------------------------------------------------------------------------

>>!
No. Django itself is guaranteed to work with any version of Python from 2.3
and higher.

If you use a Python version newer than 2.3, you will, of course, be able to
take advantage of newer Python features in your own code, along with the speed
improvements and other optimizations that have been made to the Python language
itself. But the Django framework itself should work equally well on 2.3 as it
does on 2.4 or 2.5.
<<!
>>!!
<<!!

>>!
Do I have to use mod_python?
<<!
>>!!
<<!!
----------------------------

>>!
Although we recommend mod_python for production use, you don't have to use it,
thanks to the fact that Django uses an arrangement called WSGI_. Django can
talk to any WSGI-enabled server. Other non-mod_python deployment setups are
FastCGI, SCGI or AJP. See `How to use Django with FastCGI, SCGI or AJP`_ for
full information.

Also, see the `server arrangements wiki page`_ for other deployment strategies.

If you just want to play around and develop things on your local computer, use
the development Web server that comes with Django. Things should Just Work.
<<!
>>!!
<<!!

>>!
.. _WSGI: http://www.python.org/peps/pep-0333.html
.. _How to use Django with FastCGI, SCGI or AJP: ../fastcgi/
.. _server arrangements wiki page: http://code.djangoproject.com/wiki/ServerArrangements
<<!
>>!!
<<!!

>>!
How do I install mod_python on Windows?
<<!
>>!!
<<!!
---------------------------------------

>>!
    * For Python 2.4, grab mod_python from `win32 build of mod_python for
      Python 2.4`_.
    * For Python 2.4, check out this `Django on Windows howto`_.
    * For Python 2.3, grab mod_python from http://www.modpython.org/ and read
      `Running mod_python on Apache on Windows2000`_.
    * Also, try this (not Windows-specific) `guide to getting mod_python
      working`_.
<<!
>>!!
<<!!

>>!
.. _`win32 build of mod_python for Python 2.4`: http://www.lehuen.com/nicolas/index.php/2005/02/21/39-win32-build-of-mod_python-314-for-python-24
.. _`Django on Windows howto`: http://thinkhole.org/wp/2006/04/03/django-on-windows-howto/
.. _`Running mod_python on Apache on Windows2000`: http://groups-beta.google.com/group/comp.lang.python/msg/139af8c83a5a9d4f
.. _`guide to getting mod_python working`: http://www.dscpl.com.au/articles/modpython-001.html
<<!
>>!!
<<!!

>>!
Will Django run under shared hosting (like TextDrive or Dreamhost)?
<<!
>>!!
<<!!
-------------------------------------------------------------------

>>!
See our `Django-friendly Web hosts`_ page.
<<!
>>!!
<<!!

>>!
.. _`Django-friendly Web hosts`: http://code.djangoproject.com/wiki/DjangoFriendlyWebHosts

>>!
Should I use the official version or development version?
<<!
>>!!
<<!!
---------------------------------------------------------

>>!
The Django developers improve Django every day and are pretty good about not
checking in broken code. We use the development code (from the Subversion
repository) directly on our servers, so we consider it stable. With that in
mind, we recommend that you use the latest development code, because it
generally contains more features and fewer bugs than the "official" releases.
<<!
>>!!
<<!!

>>!
Using Django
<<!
>>!!
<<!!
============

>>!
Why do I get an error about importing DJANGO_SETTINGS_MODULE?
<<!
>>!!
<<!!
-------------------------------------------------------------

>>!
Make sure that:

    * The environment variable DJANGO_SETTINGS_MODULE is set to a fully-qualified
      Python module (i.e. "mysite.settings").

    * Said module is on ``sys.path`` (``import mysite.settings`` should work).

    * The module doesn't contain syntax errors (of course).

    * If you're using mod_python but *not* using Django's request handler,
      you'll need to work around a mod_python bug related to the use of
      ``SetEnv``; before you import anything from Django you'll need to do
      the following::

            os.environ.update(req.subprocess_env)

      (where ``req`` is the mod_python request object).
<<!
>>!!
<<!!

>>!
I can't stand your template language. Do I have to use it?
<<!
>>!!
<<!!
----------------------------------------------------------

>>!
We happen to think our template engine is the best thing since chunky bacon,
but we recognize that choosing a template language runs close to religion.
There's nothing about Django that requires using the template language, so
if you're attached to ZPT, Cheetah, or whatever, feel free to use those.
<<!
>>!!
<<!!

>>!
Do I have to use your model/database layer?
<<!
>>!!
<<!!
-------------------------------------------

>>!
Nope. Just like the template system, the model/database layer is decoupled from
the rest of the framework.

The one exception is: If you use a different database library, you won't get to
use Django's automatically-generated admin site. That app is coupled to the
Django database layer.
<<!
>>!!
<<!!

>>!
How do I use image and file fields?
<<!
>>!!
<<!!
-----------------------------------

>>!
Using a ``FileField`` or an ``ImageField`` in a model takes a few steps:

    #. In your settings file, define ``MEDIA_ROOT`` as the full path to
       a directory where you'd like Django to store uploaded files. (For
       performance, these files are not stored in the database.) Define
       ``MEDIA_URL`` as the base public URL of that directory. Make sure that
       this directory is writable by the Web server's user account.

    #. Add the ``FileField`` or ``ImageField`` to your model, making sure
       to define the ``upload_to`` option to tell Django to which subdirectory
       of ``MEDIA_ROOT`` it should upload files.

    #. All that will be stored in your database is a path to the file
       (relative to ``MEDIA_ROOT``). You'll must likely want to use the
       convenience ``get_<fieldname>_url`` function provided by Django. For
       example, if your ``ImageField`` is called ``mug_shot``, you can get the
       absolute URL to your image in a template with
       ``{{ object.get_mug_shot_url }}``.
<<!
>>!!
<<!!

>>!
Databases and models
<<!
>>!!
<<!!
====================

>>!
How can I see the raw SQL queries Django is running?
<<!
>>!!
<<!!
----------------------------------------------------

>>!
Make sure your Django ``DEBUG`` setting is set to ``True``. Then, just do
this::

    >>> from django.db import connection
    >>> connection.queries
    [{'sql': 'SELECT polls_polls.id,polls_polls.question,polls_polls.pub_date FROM polls_polls',
    'time': '0.002'}]
<<!
>>!!
<<!!

>>!
``connection.queries`` is only available if ``DEBUG`` is ``True``. It's a list
of dictionaries in order of query execution. Each dictionary has the following::
<<!
>>!!
<<!!

>>!
    ``sql`` -- The raw SQL statement
    ``time`` -- How long the statement took to execute, in seconds.
<<!
>>!!
<<!!

>>!
``connection.queries`` includes all SQL statements -- INSERTs, UPDATES,
SELECTs, etc. Each time your app hits the database, the query will be recorded.
<<!
>>!!
<<!!

>>!
Can I use Django with a pre-existing database?
<<!
>>!!
<<!!
----------------------------------------------

>>!
Yes. See `Integrating with a legacy database`_.
<<!
>>!!
<<!!

>>!
.. _`Integrating with a legacy database`: ../legacy_databases/
<<!
>>!!
<<!!

>>!
If I make changes to a model, how do I update the database?
<<!
>>!!
<<!!
-----------------------------------------------------------

>>!
If you don't mind clearing data, your project's ``manage.py`` utility has an
option to reset the SQL for a particular application::
<<!
>>!!
<<!!

    manage.py reset appname

>>!
This drops any tables associated with ``appname`` and recreates them.

If you do care about deleting data, you'll have to execute the ``ALTER TABLE``
statements manually in your database. That's the way we've always done it,
because dealing with data is a very sensitive operation that we've wanted to
avoid automating. That said, there's some work being done to add partially
automated database-upgrade functionality.
<<!
>>!!
<<!!

>>!
Do Django models support multiple-column primary keys?
<<!
>>!!
<<!!
------------------------------------------------------

>>!
No. Only single-column primary keys are supported.

But this isn't an issue in practice, because there's nothing stopping you from
adding other constraints (using the ``unique_together`` model option or
creating the constraint directly in your database), and enforcing the
uniqueness at that level. Single-column primary keys are needed for things such
as the admin interface to work; e.g., you need a simple way of being able to
specify an object to edit or delete.

How do I add database-specific options to my CREATE TABLE statements, such as specifying MyISAM as the table type?
<<!
>>!!
<<!!
------------------------------------------------------------------------------------------------------------------

>>!
We try to avoid adding special cases in the Django code to accommodate all the
database-specific options such as table type, etc. If you'd like to use any of
these options, create an `SQL initial data file`_ that contains ``ALTER TABLE``
statements that do what you want to do. The initial data files are executed in
your database after the ``CREATE TABLE`` statements.

For example, if you're using MySQL and want your tables to use the MyISAM table
type, create an initial data file and put something like this in it::
<<!
>>!!
<<!!

    ALTER TABLE myapp_mytable ENGINE=MyISAM;

>>!
As explained in the `SQL initial data file`_ documentation, this SQL file can
contain arbitrary SQL, so you can make any sorts of changes you need to make.
<<!
>>!!
<<!!

>>!
.. _SQL initial data file: ../model-api/#providing-initial-sql-data
<<!
>>!!
<<!!

>>!
Why is Django leaking memory?
<<!
>>!!
<<!!
-----------------------------

>>!
Django isn't known to leak memory. If you find your Django processes are
allocating more and more memory, with no sign of releasing it, check to make
sure your ``DEBUG`` setting is set to ``True``. If ``DEBUG`` is ``True``, then
Django saves a copy of every SQL statement it has executed.

(The queries are saved in ``django.db.connection.queries``. See
`How can I see the raw SQL queries Django is running?`_.)

To fix the problem, set ``DEBUG`` to ``False``.

If you need to clear the query list manually at any point in your functions,
just call ``reset_queries()``, like this::
<<!
>>!!
<<!!

    from django import db
    db.reset_queries()

>>!
The admin site
<<!
>>!!
<<!!
==============

>>!
I can't log in. When I enter a valid username and password, it just brings up the login page again, with no error messages.
<<!
>>!!
<<!!
---------------------------------------------------------------------------------------------------------------------------

>>!
The login cookie isn't being set correctly, because the domain of the cookie
sent out by Django doesn't match the domain in your browser. Try these two
things:

    * Set the ``SESSION_COOKIE_DOMAIN`` setting in your admin config file
      to match your domain. For example, if you're going to
      "http://www.mysite.com/admin/" in your browser, in
      "myproject.settings" you should set ``SESSION_COOKIE_DOMAIN = 'www.mysite.com'``.

    * Some browsers (Firefox?) don't like to accept cookies from domains that
      don't have dots in them. If you're running the admin site on "localhost"
      or another domain that doesn't have a dot in it, try going to
      "localhost.localdomain" or "127.0.0.1". And set
      ``SESSION_COOKIE_DOMAIN`` accordingly.

I can't log in. When I enter a valid username and password, it brings up the login page again, with a "Please enter a correct username and password" error.
<<!
>>!!
<<!!
-----------------------------------------------------------------------------------------------------------------------------------------------------------

>>!
If you're sure your username and password are correct, make sure your user
account has ``is_active`` and ``is_staff`` set to True. The admin site only
allows access to users with those two fields both set to True.
<<!
>>!!
<<!!

>>!
How can I prevent the cache middleware from caching the admin site?
<<!
>>!!
<<!!
-------------------------------------------------------------------

>>!
Set the ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting to ``True``. See the
`cache documentation`_ for more information.
<<!
>>!!
<<!!

>>!
.. _cache documentation: ../cache/#the-per-site-cache
<<!
>>!!
<<!!

>>!
How do I automatically set a field's value to the user who last edited the object in the admin?
<<!
>>!!
<<!!
-----------------------------------------------------------------------------------------------

>>!
At this point, Django doesn't have an official way to do this. But it's an oft-requested
feature, so we're discussing how it can be implemented. The problem is we don't want to couple
the model layer with the admin layer with the request layer (to get the current user). It's a
tricky problem.

One person hacked up a `solution that doesn't require patching Django`_, but note that it's an
unofficial solution, and there's no guarantee it won't break at some point.
<<!
>>!!
<<!!

>>!
.. _solution that doesn't require patching Django: http://lukeplant.me.uk/blog.php?id=1107301634
<<!
>>!!
<<!!

>>!
How do I limit admin access so that objects can only be edited by the users who created them?
<<!
>>!!
<<!!
---------------------------------------------------------------------------------------------

>>!
See the answer to the previous question.

My admin-site CSS and images showed up fine using the development server, but they're not displaying when using mod_python.
<<!
>>!!
<<!!
---------------------------------------------------------------------------------------------------------------------------

>>!
See `serving the admin files`_ in the "How to use Django with mod_python"
documentation.
<<!
>>!!
<<!!

>>!
.. _serving the admin files: ../modpython/#serving-the-admin-files
<<!
>>!!
<<!!

>>!
My "list_filter" contains a ManyToManyField, but the filter doesn't display.
<<!
>>!!
<<!!
----------------------------------------------------------------------------

>>!
Django won't bother displaying the filter for a ``ManyToManyField`` if there
are fewer than two related objects.

For example, if your ``list_filter`` includes ``sites``, and there's only one
site in your database, it won't display a "Site" filter. In that case,
filtering by site would be meaningless.
<<!
>>!!
<<!!

>>!
How can I customize the functionality of the admin interface?
<<!
>>!!
<<!!
-------------------------------------------------------------

>>!
You've got several options. If you want to piggyback on top of an add/change
form that Django automatically generates, you can attach arbitrary JavaScript
modules to the page via the model's ``class Admin`` ``js`` parameter. That
parameter is a list of URLs, as strings, pointing to JavaScript modules that
will be included within the admin form via a ``<script>`` tag.

If you want more flexibility than simply tweaking the auto-generated forms,
feel free to write custom views for the admin. The admin is powered by Django
itself, and you can write custom views that hook into the authentication
system, check permissions and do whatever else they need to do.

If you want to customize the look-and-feel of the admin interface, read the
next question.
<<!
>>!!
<<!!

>>!
The dynamically-generated admin site is ugly! How can I change it?
<<!
>>!!
<<!!
------------------------------------------------------------------

>>!
We like it, but if you don't agree, you can modify the admin site's
presentation by editing the CSS stylesheet and/or associated image files. The
site is built using semantic HTML and plenty of CSS hooks, so any changes you'd
like to make should be possible by editing the stylesheet. We've got a
`guide to the CSS used in the admin`_ to get you started.
<<!
>>!!
<<!!

>>!
.. _`guide to the CSS used in the admin`: ../admin_css/
<<!
>>!!
<<!!

>>!
How do I create users without having to edit password hashes?
<<!
>>!!
<<!!
-------------------------------------------------------------

>>!
If you'd like to use the admin site to create users, upgrade to the Django
development version, where this problem was fixed on Aug. 4, 2006.

You can also use the Python API. See `creating users`_ for full info.
<<!
>>!!
<<!!

>>!
.. _creating users: ../authentication/#creating-users
<<!
>>!!
<<!!

>>!
Contributing code
<<!
>>!!
<<!!
=================

>>!
How can I get started contributing code to Django?
<<!
>>!!
<<!!
--------------------------------------------------

>>!
Thanks for asking! We've written an entire document devoted to this question.
It's titled `Contributing to Django`_.
<<!
>>!!
<<!!

>>!
.. _Contributing to Django: ../contributing/
<<!
>>!!
<<!!

>>!
I submitted a bug fix in the ticket system several weeks ago. Why are you ignoring my patch?
<<!
>>!!
<<!!
--------------------------------------------------------------------------------------------

>>!
Don't worry: We're not ignoring you!

It's important to understand there is a difference between "a ticket is being
ignored" and "a ticket has not been attended to yet." Django's ticket system
contains hundreds of open tickets, of various degrees of impact on end-user
functionality, and Django's developers have to review and prioritize.

Besides, if your feature request stands no chance of inclusion in Django, we
won't ignore it -- we'll just close the ticket. So if your ticket is still
open, it doesn't mean we're ignoring you; it just means we haven't had time to
look at it yet.
<<!
>>!!
<<!!
Last modified 5 years ago Last modified on 01/26/2010 09:17:03 AM
Back to Top