diff --git a/docs/intro/tutorial02.txt b/docs/intro/tutorial02.txt index 3cda0d38d6..b21e625c32 100644 --- a/docs/intro/tutorial02.txt +++ b/docs/intro/tutorial02.txt @@ -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 `; this checks for any problems in diff --git a/docs/topics/db/models.txt b/docs/topics/db/models.txt index aefb35ed9c..2a4a7d58df 100644 --- a/docs/topics/db/models.txt +++ b/docs/topics/db/models.txt @@ -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 `. +* 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 ============