mirror of
https://github.com/django/django.git
synced 2024-12-23 09:36:06 +00:00
4a954cfd11
This patch does not remove all occurrences of the words in question. Rather, I went through all of the occurrences of the words listed below, and judged if they a) suggested the reader had some kind of knowledge/experience, and b) if they added anything of value (including tone of voice, etc). I left most of the words alone. I looked at the following words: - simply/simple - easy/easier/easiest - obvious - just - merely - straightforward - ridiculous Thanks to Carlton Gibson for guidance on how to approach this issue, and to Tim Bell for providing the idea. But the enormous lion's share of thanks go to Adam Johnson for his patient and helpful review.
92 lines
3.6 KiB
Plaintext
92 lines
3.6 KiB
Plaintext
=========================
|
|
FAQ: Databases and models
|
|
=========================
|
|
|
|
.. _faq-see-raw-sql-queries:
|
|
|
|
How can I see the raw SQL queries Django is running?
|
|
====================================================
|
|
|
|
Make sure your Django :setting:`DEBUG` setting is set to ``True``.
|
|
Then 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 :setting:`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.
|
|
|
|
If you are using :doc:`multiple databases</topics/db/multi-db>`, you can use the
|
|
same interface on each member of the ``connections`` dictionary::
|
|
|
|
>>> from django.db import connections
|
|
>>> connections['my_db_alias'].queries
|
|
|
|
If you need to clear the query list manually at any point in your functions,
|
|
call ``reset_queries()``, like this::
|
|
|
|
from django.db import reset_queries
|
|
reset_queries()
|
|
|
|
Can I use Django with a pre-existing database?
|
|
==============================================
|
|
|
|
Yes. See :doc:`Integrating with a legacy database </howto/legacy-databases>`.
|
|
|
|
If I make changes to a model, how do I update the database?
|
|
===========================================================
|
|
|
|
Take a look at Django's support for :mod:`schema migrations
|
|
<django.db.migrations>`.
|
|
|
|
If you don't mind clearing data, your project's ``manage.py`` utility has a
|
|
:djadmin:`flush` option to reset the database to the state it was in
|
|
immediately after :djadmin:`migrate` was executed.
|
|
|
|
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 single value to specify
|
|
an object to edit or delete.
|
|
|
|
Does Django support NoSQL databases?
|
|
====================================
|
|
|
|
NoSQL databases are not officially supported by Django itself. There are,
|
|
however, a number of side project and forks which allow NoSQL functionality in
|
|
Django, like `Django non-rel`_.
|
|
|
|
You can also take a look on `the wiki page`_ which discusses some alternatives.
|
|
|
|
.. _`Django non-rel`: http://django-nonrel.org/
|
|
.. _`the wiki page`: https://code.djangoproject.com/wiki/NoSqlSupport
|
|
|
|
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 a migration with a
|
|
:class:`~django.db.migrations.operations.RunSQL` operation that contains
|
|
``ALTER TABLE`` statements that do what you want to do.
|
|
|
|
For example, if you're using MySQL and want your tables to use the MyISAM table
|
|
type, use the following SQL::
|
|
|
|
ALTER TABLE myapp_mytable ENGINE=MyISAM;
|