python建站与java建站有何不同_小白python建站的一些准备（八）

十六、QuerySet切片

    QuerySet可以像python的列表一样进行切片取值，例如：

res = Book.objects.get_queryset()[1:2][]>>'SELECT `book`.`id`, `book`.`name`, `book`.`pages`, `book`.`price`, `book`.`rating`, `book`.`author_id`, `book`.`publisher_id` FROM `book` LIMIT 1 OFFSET 1'

可以看到切片在sql层面就利用了LIMIT 和OFFSET 来帮我们处理，所以比取值到python内存当中再进行排除更加高效。需要注意的是Manager对象并没有拷贝QuerySet的切片方法。get_queryset用于Return a new QuerySet object，那么get_queryset和all()有什么区别呢？答案是没有区别，all()底层的源码显示return self.get_queryset()。

十七、Django何时会将QuerySet转化成SQL？

• 迭代，遍历QuerySet对象时

• 使用步长做切片操作，注意：单纯切片并不会直接转成SQL。

  Book.objects.all()[1:2:1] 

• 调用len函数获取QuerySet中有多少条数据。

• 调用list函数讲一个QuerySet对象转换成list对象会立刻执行SQL。

• 判断。如果将某个QuerySet放在if判断中，也会立刻执行。

十八、Django的ORM迁移

• makemigrations，将模型生成迁移脚本，模型所在的app必须在INSTALLED_APPS当中。可以在后面跟上app_label(一个或者多个)，以针对特定的app生成迁移脚本；或者指定迁移的脚本名称：--name，如果自己想定制迁移脚本，可以使用--empty来生成空的迁移文件。

python manage.py makemigrations book --name "rename_migrations"

•  migrate，将新生成的迁移脚本映射到数据库中。后面跟上app_label，以将特定的app下面的迁移脚本迁移到数据库中。

  我们可以找到数据库中存在一个名为django_migrations的表，Django之所以能够不重复执行我们的迁移脚本，就在于我们每执行一次迁移脚本，则该表会同步生成一条字段为app名称，name为迁移脚本名和修改日期的数据。当然这个时间是UTC时间。

  

      当数据库中django_migrations迁移版本和代码中的迁移脚本版本不一致时解决方法(判断菜鸟和大神的迁移命令)：--fake和--fake-initial，我们在执行migrate时必定会修改数据库的表结构，而--fake的作用就是将制定的迁移脚本名称添加到django_migrations表，但是不会真正的去执行SQL语句，修改数据库中表的结构。

      先来看下--fake命令，例如，在django_migrations表中，有5条迁移数据，但是现在我删除第5条数据，然后再重新执行迁移脚本，这个时候就会报错。因为第5条数据本来记录了price字段被删除，现在0004_remove_book_price.py再次执行删除price字段的操作，必定是报错的

  

而这种原本就执行了某条迁移操作，但是由于django_migrations表中的数据不完整导致的"Can't DROP 'price'; check that column/key exists"错误就可以考虑使用--fake命令来解决，当然这个前提是建立在你对这个迁移文件及数据库很了解的前提下。

而--fake-initial将第一次生成的迁移脚本映射到数据库，但不会真正的去执行sql语句。主要用于当你不知道数据库中的哪个地方不一致来生成同步的迁移文件。具体操作为：先将模型和数据库里面对应的表内容保持一致；

再将对应模型的migrations文件夹(示例为book)下面的所有迁移脚本删除

将django_migrations表中所有与该模型有关的app删除，如下

那么此时，django_migrations和我们migrations文件夹下面的迁移脚本就一致了，再使用makemigrations生成迁移脚本。

但此时如果我们使用migrate进行实际上的迁移，还是会报错，因为数据库中已经存在了这张book表，那么就可以使用--fake-initial或者--fake来解决了。

• showmigrations，查看某个app下面的迁移文件，默认是INSTALLED_APPS中的所有app。

• sqlmigrate，查看转化的实际sql语句，实例如下：

python manage.py sqlmigrate book 0002>ALTER TABLE `book_book` ADD COLUMN `content` varchar(200) NULL;

十九、根据已有的数据库生成ORM模型

    当你配置好数据库连接时，使用如下命令，可一键将数据库中的表结构转化成ORM模型

python manage.py inspectdb > log........class BookBook(models.Model):    name = models.CharField(max_length=100)    content = models.CharField(max_length=200, blank=True, null=True)    class Meta:        # managed 删除或者为Ture即        # 可让django自动帮我们处理增加或者删除的字段        managed = False        db_table = 'book_book'        class DjangoMigrations(models.Model):    app = models.CharField(max_length=255)    name = models.CharField(max_length=255)    applied = models.DateTimeField()    class Meta:        managed = False        db_table = 'django_migrations'

    对于以上的模型我们可以进行修正。

    修正模型名称，然后根据不同的模型丢入到不同的app中，方便管理，需要注意的是如果建立了外键关联，当需要引用不同app下面的模型时，需要写完整路径 ForeignKey('Article.Tag')，即app.model的形式。

    删除managed = False，这样django才可以管理模型中的字段(如我们使用python manage.py makemigrations生成迁移脚本是因为我们的managed = true，如果为False，那么是无法生成正确的迁移脚本的)。ManyToManyField的可以通过db_table来指定数据库里面的表名。

    此时就可以使用如下命令将相应模型的脚本生成

python manage.py migrate front# python manage.py migrate front --fake-initial# django3.1亲测不用使用--fake-initial