mirror of
https://github.com/django/django.git
synced 2025-06-05 03:29:12 +00:00
Removing unnecessary section in the second step of the tutorial
This commit is contained in:
parent
adae619426
commit
fdfc8b03ac
@ -256,75 +256,7 @@ they're designed to be human-editable in case you want to manually tweak how
|
||||
Django changes things.
|
||||
|
||||
There's a command that will run the migrations for you and manage your database
|
||||
schema automatically - that's called :djadmin:`migrate`, and we'll come to it in a
|
||||
moment - but first, let's see what SQL that migration would run. The
|
||||
:djadmin:`sqlmigrate` command takes migration names and returns their SQL:
|
||||
|
||||
.. console::
|
||||
|
||||
$ python manage.py sqlmigrate polls 0001
|
||||
|
||||
You should see something similar to the following (we've reformatted it for
|
||||
readability):
|
||||
|
||||
.. code-block:: sql
|
||||
|
||||
BEGIN;
|
||||
--
|
||||
-- Create model Question
|
||||
--
|
||||
CREATE TABLE "polls_question" (
|
||||
"id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
|
||||
"question_text" varchar(200) NOT NULL,
|
||||
"pub_date" timestamp with time zone NOT NULL
|
||||
);
|
||||
--
|
||||
-- Create model Choice
|
||||
--
|
||||
CREATE TABLE "polls_choice" (
|
||||
"id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
|
||||
"choice_text" varchar(200) NOT NULL,
|
||||
"votes" integer NOT NULL,
|
||||
"question_id" bigint NOT NULL
|
||||
);
|
||||
ALTER TABLE "polls_choice"
|
||||
ADD CONSTRAINT "polls_choice_question_id_c5b4b260_fk_polls_question_id"
|
||||
FOREIGN KEY ("question_id")
|
||||
REFERENCES "polls_question" ("id")
|
||||
DEFERRABLE INITIALLY DEFERRED;
|
||||
CREATE INDEX "polls_choice_question_id_c5b4b260" ON "polls_choice" ("question_id");
|
||||
|
||||
COMMIT;
|
||||
|
||||
Note the following:
|
||||
|
||||
* The exact output will vary depending on the database you are using. The
|
||||
example above is generated for PostgreSQL.
|
||||
|
||||
* Table names are automatically generated by combining the name of the app
|
||||
(``polls``) and the lowercase name of the model -- ``question`` and
|
||||
``choice``. (You can override this behavior.)
|
||||
|
||||
* Primary keys (IDs) are added automatically. (You can override this, too.)
|
||||
|
||||
* By convention, Django appends ``"_id"`` to the foreign key field name.
|
||||
(Yes, you can override this, as well.)
|
||||
|
||||
* The foreign key relationship is made explicit by a ``FOREIGN KEY``
|
||||
constraint. Don't worry about the ``DEFERRABLE`` parts; it's telling
|
||||
PostgreSQL to not enforce the foreign key until the end of the transaction.
|
||||
|
||||
* It's tailored to the database you're using, so database-specific field types
|
||||
such as ``auto_increment`` (MySQL), ``bigint PRIMARY KEY GENERATED BY DEFAULT
|
||||
AS IDENTITY`` (PostgreSQL), or ``integer primary key autoincrement`` (SQLite)
|
||||
are handled for you automatically. Same goes for the quoting of field names
|
||||
-- e.g., using double quotes or single quotes.
|
||||
|
||||
* The :djadmin:`sqlmigrate` command doesn't actually run the migration on your
|
||||
database - instead, it prints it to the screen so that you can see what SQL
|
||||
Django thinks is required. It's useful for checking what Django is going to
|
||||
do or if you have database administrators who require SQL scripts for
|
||||
changes.
|
||||
schema automatically - that's called :djadmin:`migrate`.
|
||||
|
||||
If you're interested, you can also run
|
||||
:djadmin:`python manage.py check <check>`; this checks for any problems in
|
||||
|
@ -48,7 +48,9 @@ The above ``Person`` model would create a database table like this:
|
||||
Some technical notes:
|
||||
|
||||
* The name of the table, ``myapp_person``, is automatically derived from
|
||||
some model metadata but can be overridden. See :ref:`table-names` for more
|
||||
some model metadata but can be overridden, normally are automatically
|
||||
generated by combining the name of the app (``myapp``) and the lowercase
|
||||
name of the model (``person``) . See :ref:`table-names` for more
|
||||
details.
|
||||
|
||||
* An ``id`` field is added automatically, but this behavior can be
|
||||
@ -58,6 +60,15 @@ Some technical notes:
|
||||
syntax, but it's worth noting Django uses SQL tailored to the database
|
||||
backend specified in your :doc:`settings file </topics/settings>`.
|
||||
|
||||
* The foreign key relationships are made explicit by a ``FOREIGN KEY``
|
||||
constraint.
|
||||
|
||||
* It's tailored to the database you're using, so database-specific field types
|
||||
such as ``auto_increment`` (MySQL), ``bigint PRIMARY KEY GENERATED BY DEFAULT
|
||||
AS IDENTITY`` (PostgreSQL), or ``integer primary key autoincrement`` (SQLite)
|
||||
are handled for you automatically. Same goes for the quoting of field names
|
||||
-- e.g., using double quotes or single quotes.
|
||||
|
||||
Using models
|
||||
============
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user