开始Django之旅-part2_Django和数据库mysql_list of time zones django-CSDN博客

本文链接：https://blog.csdn.net/qq_36638788/article/details/105511518

开始Django之旅-part2_Django和数据库mysql

前言
建立数据库
创建models
激活models
API
Django Admin介绍
创建一个管理员用户

前言

假定你已经看了上一篇文章并且完成了任务，在这里，在下将带领你建立数据库，创建你的第一个model，然后快速的了解一下由Django自动生成的admin地址。

建立数据库

现在，打开mysite/settings.py.它是一个带有模块级别变量的Python module（模块）,是一个Django设置文件。

默认情况下，该配置文件使用的是SQLite数据库，如果你刚开始接触数据库、或者你仅仅对Django有兴趣，SQLite是一个最容易的选择。SQLite内嵌在Python中，所以你不需要在安装软件啦。然而，当启动你第一个正式的项目时，你可能想要使用一个像PostgreSQL容量可伸缩的数据库，避免在使用Django一段时间之后转换数据库的痛苦。

如果你希望使用另一种数据库，首先安装合适的数据库绑定包，然后更改在DATABASE ‘default’ 下的关键字，去匹配你的数据库的连接设置：

ENGING（任选一个）

’django.db.backends.sqlite3’
’django.db.backends.postgresql’
’django.db.backends.mysql’
’django.db.backends.oracle’

NAME

这是你数据库的名字。如果你使用的是默认SQLite，且想要数据库文件保存在计算机任何的一个地方，这里的NAME应该是一个完整路径，包括数据库文件的文件名。默认值是os.path.join(BASE_DIR, ‘db.sqlite3’),这使得数据库文件存储在项目目录中。

如果你使用其他的数据库，像URSE、PASSWORD和HOST等额外的设置参数必须添加，像这样：（更多配置细节）
在这里插入图片描述 注意：如果你使用其他的数据库，确保：
1.你已经建立了数据库（create database database_name）
2.确保你所提供的用户有建立数据库的权限，因为后续要用到的测试数据库，是需要自动创建的
3.如果你使用的是SQLite，你不需要提前做任何事，当需要的时候，数据库文件就会自动建好

当你正在编辑mysite/settings.py时，设置TIME_ZONE(默认是America/Chicago,该设置同样在database-default中设置)为你当前的时区（Asia/Hong_Kong）。list of time zones

同样的，注意一下文件顶部的INSTALLED_APPS设置，它包括了所有Django应用的名称，它们会在Django启动的时候激活，Apps可以被用于多个项目。你可以将它们打包，然后发布它们，就可以让别人在他们的项目中使用。
在这里插入图片描述默认情况下，INSTALLED_APPS包含了一下apps，它们和Django一起运行。

‘django.contrib.admin’, 管理员地址，一会你就会用到
‘django.contrib.auth’,一个认证系统
‘django.contrib.contenttypes’,一个内容类型的框架
‘django.contrib.sessions’,一个session框架
‘django.contrib.messages’,一个通信框架
‘django.contrib.staticfiles’,一个管理静态文件的框架

这些apps一般情况下都是默认包含的。

其中一些apps最少用到一个数据库表，所以我们在使用这些apps之前就需要创建数据库表，开始建表：

...\> py manage.py migrate

migrate命令检查了INSTALLED_APPS设置，并根据mysite/settings.py中的数据库设置创建了任何必要的数据库表，这些数据库表伴随着app的转移而转移（我们之后会讲到），你会在cmd看到它的每个移动信息。如果你有兴趣的话，运行你的数据库，查看你的数据库表。

温馨提示：就像我们之前说过的一样，这些默认的app一般都被包含在项目中，如果你不需要他们，在运行migrate之前随便注释掉或删掉。migrate命令只会迁移INSTALLED_APPS中包含的app数据库表。

创建models

现在我们要定义你的models，必要情况下，你的数据库会有一些元数据的设计。

什么是model呢？

一个model是你的数据单一的、确定的真实来源。它包含了必要的数据类型和你存储的数据的行为。Django遵循了DRY原则。目标就是在一个地方确定你的数据模型，然后自动的从那里得到一些东西。

model包含了migrations（迁移数据库表），比如，migrations完全的来源于你的models文件，model本质上就是一个记录，Django可以通过它去更新你的数据库体系，来匹配当前的models。

在我们的投票app中，我们会创建两个models：Question和Choice。一个Question有一个question和一个发布日期，一个Choice有两个字段：选择的文本和投票记数。每个Choice都和Question关联。

这些概念都是通过Python类表现出来的。现在编辑polls/models.py文件：

from django.db import models


class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')


class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

在这里，每一个model都被 django.db.models.Model的子类表示，每一个model都有许多变量，他们代表在model中的数据库字段。

每一个字段都被一个Field类实例所表示，比如，CharField表示字符字段，DateTimeField表示 datetimes字段。这些告诉Django存储每个数据为何种类型。

每一个Field实例（question_text,pub_date）的名字并不是字段名字，知识机器友好的命名格式。你会在你的Python代码中使用它们的值，并且你的数据库会使用它作为列名。

你可以在Field类中的第一个可选参数中设置一个读得懂的名字，这被应用到Django的一部分，用来自我检查，它也是作为一个提示文档的备份。如果这个字段没有被提供，Django会使用机器可读的命名。在这个例子中，我们只定义了Question.pub_date的人可读的命名，对于其他的字段，机器可读的命名已经足够作为人可读的命名了。

一些字段类要求必须有某些参数，比如，CharFild要求你给出max_length。这些不仅会应用于数据库架构中，也会用于校验，我们不久就会看到。

一个字段也可以有各种各样的可选参数，在本例中，我们会设置vates的默认值为0.

最后，注意已经定义的关系，使用ForeignKey，这会桃酥Django每一个Choice都和某一个Question相关联。Django支持所有普遍的数据库关系模式：多对一、多对多和一对一。

激活models

虽然model的代码量比较少，但是却给了Django大量的信息。有了它，Django就可以：

为polls app创建一个数据库架构（create table ）
创建一个通过Question和Choice对象就可以访问数据库的API。

但是首先我们需要去告诉我们的项目polls app已经安装了。
在这里插入图片描述现在Django已经包含了polls app，运行下面的命令：

...\> py manage.py makemigrations polls

就会的到下面的输出：

Migrations for 'polls':
  polls/migrations/0001_initial.py
    - Create model Question
    - Create model Choice

通过运行makemigrations,有告诉了Django你已经对你的models做了改变，并且，你希望将这些改变当做一个migration被存储。

Migration就是Django存储对模型（以及数据库模式）的更改的方式——它们写在硬盘上。你可以读这些migration，就是文件polls/migrations/0001_initial.py。别担心，每当这种文件生成之后，你不需要每次都阅读，但是，它们被设计为可编辑是为了让你可以手工的修改Django改变东西的方式。

这里有一个启动migrations的命令，可以自动的帮你管理数据库结构——这就是migrate，我们一会还会回到这里，但是首先，让我们看一些migration将会运行什么SQL语句。sqlmigrate命令会读取migration的名字，然后返回sql语句。

...\> py manage.py sqlmigrate polls 0001

你会看到类似下面的东西：

...\mysite>py manage.py sqlmigrate polls 0001
--
-- Create model Question
--
CREATE TABLE `polls_question` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `question_text` varchar(200) NOT NULL, `pub_date` datetime(6) NO
T NULL);
--
-- Create model Choice
--
CREATE TABLE `polls_choice` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `choice_text` varchar(200) NOT NULL, `votes` integer NOT NULL, `qu
estion_id` integer 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`);

注意：
1.确切的输出信息取决于你正在使用的什么数据库，上面的例子急于mysql生成的
2.表名是结合app名字自动生成的，由model名字的小写和question和choice组成。（你可以重载这个方法）
3.字段ids是自动添加的。（你可以重载这个方法）
4.按照惯例，Django后面追加‘_id’表示外键关键字段名。（你可以重载这个方法）
5.外键关系是由关键约束明确规定的，不用担心建表之后再执行外键约束，它这是告诉mysql在事务完成之前不要强行外键约束
6.这是对你所使用的数据库定制的，所以具体的数据库字段类型都会自动的帮你处理好。对于引用字段名，例如使用双引号还是单引号也是一样的。
7.sqlmigrate命令不会在你的数据库上自动运行migration，事实上，它打印sql语句到屏幕上，你就可以看到Django认为需要什么SQL语句。这有助于确认Django要做什么，或者数据库管理员需要这些sql语句做一些修改。

如果你有兴趣，你也可以运行 python manage.py check;这会帮你检查你项目中的任何问题，且不会执行migrations，不会影响数据库。

现在，再次运行migrate在数据库中创建这些model表：

...\> py manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, polls, sessions
Running migrations:
  Applying polls.0001_initial... OK

migrate命令会接受所有还没有被应用的migrations（Django通过一个在你数据库中叫jdango_migrations的表来追中哪一个migration还没有被应用）并且运行它们，并且和数据库对比，同步化你对models做的改变和数据库结构。

migrations非常强大，能让你随时改变你的models，当你开发你的项目时，不需要删除你的数据库或表在建一个新的。它会专门的更新你正在运行的数据库，且不会丢失数据。我们会在后面的部分更深层次的讲解，但是现在，记住修改model的三步：

修改你的models（在models.py）
由于修改，运行python manage.py makemigrations 去创建migrations
运行python manage.py migrate 去应用这些修改到数据库中

把这些命令分开是因为你需要提交migrations给你的版本控制系统并且应用到你的app中；它们不仅仅是为了让你的开发更容易，在开发中对于其他的开发者也是有用的。

API

现在，让我们跳到与Python交互的的shell命令界面，尝试一些提供给你的Django API。使用下面的命令，调用Python shell：

...\> py manage.py shell

我们正在使用这个替换了简单的输入python，因为manage.py设置了DJANGO_SETTINGS_MODULE 环境变量，它为Django提供了指向mysite/settings.py文件的路径。

如果你在shell中，你可以使用参考文档API

>>> from polls.models import Choice, Question  # Import the model classes we just wrote.

# No questions are in the system yet.
>>> Question.objects.all()
<QuerySet []>

# Create a new Question.
# Support for time zones is enabled in the default settings file, so
# Django expects a datetime with tzinfo for pub_date. Use timezone.now()
# instead of datetime.datetime.now() and it will do the right thing.
>>> from django.utils import timezone
>>> q = Question(question_text="What's new?", pub_date=timezone.now())

# Save the object into the database. You have to call save() explicitly.
>>> q.save()

# Now it has an ID.
>>> q.id
1

# Access model field values via Python attributes.
>>> q.question_text
"What's new?"
>>> q.pub_date
datetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=<UTC>)

# Change values by changing the attributes, then calling save().
>>> q.question_text = "What's up?"
>>> q.save()

# objects.all() displays all the questions in the database.
>>> Question.objects.all()
<QuerySet [<Question: Question object (1)>]>

这里使用美国时区输出的，但数据库中以香港时区存储

等等，这个<QuerySet [<Question: Question object (1)>]>根本就没有展示出这个对象，在Question model（polls/models.py）中来修改一下，Question和Choice都添加__str__（）方法。
在这里插入图片描述

在models中导入__str__（）方法是非常重要的，不仅仅是为了当你在处理即时交互提供自己便利，也是因为对通过Django的自动生成管理有帮助。

再来添加一个自定义方法：

import datetime

from django.db import models
from django.utils import timezone


class Question(models.Model):
    # ...
    def was_published_recently(self):
        return self.pub_date >= timezone.now() - datetime.timedelta(days=1)

注意导入datetime包和相关工具，如果你对python中的时区处理不太熟悉，你可以参考这里time zone。

保存上面的修改，再次运行python manage.py shell，打开一个新的Python shell交互界面：

>>> from polls.models import Choice, Question

# Make sure our __str__() addition worked.
>>> Question.objects.all()
<QuerySet [<Question: What's up?>]>

# Django provides a rich database lookup API that's entirely driven by
# keyword arguments.
>>> Question.objects.filter(id=1)
<QuerySet [<Question: What's up?>]>
>>> Question.objects.filter(question_text__startswith='What')
<QuerySet [<Question: What's up?>]>

# Get the question that was published this year.
>>> from django.utils import timezone
>>> current_year = timezone.now().year
>>> Question.objects.get(pub_date__year=current_year)
<Question: What's up?>

# Request an ID that doesn't exist, this will raise an exception.
>>> Question.objects.get(id=2)
Traceback (most recent call last):
    ...
DoesNotExist: Question matching query does not exist.

# Lookup by a primary key is the most common case, so Django provides a
# shortcut for primary-key exact lookups.
# The following is identical to Question.objects.get(id=1).
>>> Question.objects.get(pk=1)
<Question: What's up?>

# Make sure our custom method worked.
>>> q = Question.objects.get(pk=1)
>>> q.was_published_recently()
True

# Give the Question a couple of Choices. The create call constructs a new
# Choice object, does the INSERT statement, adds the choice to the set
# of available choices and returns the new Choice object. Django creates
# a set to hold the "other side" of a ForeignKey relation
# (e.g. a question's choice) which can be accessed via the API.
>>> q = Question.objects.get(pk=1)

# Display any choices from the related object set -- none so far.
>>> q.choice_set.all()
<QuerySet []>

# Create three choices.
>>> q.choice_set.create(choice_text='Not much', votes=0)
<Choice: Not much>
>>> q.choice_set.create(choice_text='The sky', votes=0)
<Choice: The sky>
>>> c = q.choice_set.create(choice_text='Just hacking again', votes=0)

# Choice objects have API access to their related Question objects.
>>> c.question
<Question: What's up?>

# And vice versa: Question objects get access to Choice objects.
>>> q.choice_set.all()
<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>
>>> q.choice_set.count()
3

# The API automatically follows relationships as far as you need.
# Use double underscores to separate relationships.
# This works as many levels deep as you want; there's no limit.
# Find all Choices for any question whose pub_date is in this year
# (reusing the 'current_year' variable we created above).
>>> Choice.objects.filter(question__pub_date__year=current_year)
<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>

# Let's delete one of the choices. Use delete() for that.
>>> c = q.choice_set.filter(choice_text__startswith='Just hacking')
>>> c.delete()