mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-06-26 13:59:12 +00:00
Code Issues 32 Releases Wiki Activity

Removing unnecessary section in the second step of the tutorial

Browse Source
This commit is contained in:
Andreu Vallbona 2024-06-08 15:15:25 +02:00
parent adae619426
commit fdfc8b03ac
No known key found for this signature in database
GPG Key ID: 6518C0CC0E2BE73D
2 changed files with 13 additions and 70 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
docs/intro/tutorial02.txt
View File

@ -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

13
docs/topics/db/models.txt
View File

@ -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
============