转 dango的模型总结 and django-关于manage.py migrate无效的问题

http://iluoxuan.iteye.com/blog/1703061

1：用过django就知道django的model有多方便：

首先介绍下django的模型有哪些属性：先看例子：

Django 模型类的Meta是一个内部类，它用于定义一些Django模型类的行为特性。以下对此作一总结：

• abstract

     这个属性是定义当前的模型类是不是一个抽象类。所谓抽象类是不会对应数据库表的。一般我们用它来归纳一些公共属性字段，然后继承它的子类可以继承这些字段。比如下面的代码中Human是一个抽象类，Employee是一个继承了Human的子类，那么在运行syncdb命令时，不会生成Human表，但是会生成一个Employee表，它包含了Human中继承来的字段，以后如果再添加一个Customer模型类，它可以同样继承Human的公共属性：

class Human(models.Model):
    name=models.CharField(max_length=100)
    GENDER_CHOICE=((u'M',u'Male'),(u'F',u'Female'),)
    gender=models.CharField(max_length=2,choices=GENDER_CHOICE,null=True)
    class Meta:
        abstract=True
class Employee(Human):
    joint_date=models.DateField()
class Customer(Human):
    first_name=models.CharField(max_length=100)
    birth_day=models.DateField()

上面的代码，执行python manage.py syncdb 后的输出结果入下，可以看出Human表并没有被创建:

$ python manage.py syncdb
Creating tables ...
Creating table myapp_employee
Creating table myapp_customer
Installing custom SQL ...
Installing indexes ...
No fixtures found.

• app_label

app_label这个选项只在一种情况下使用，就是你的模型类不在默认的应用程序包下的models.py文件中，这时候你需要指定你这个模型类是那个应用程序的。比如你在其他地方写了一个模型类，而这个模型类是属于myapp的，那么你这是需要指定为：

app_label='myapp'

• db_table

db_table是用于指定自定义数据库表名的。Django有一套默认的按照一定规则生成数据模型对应的数据库表名，如果你想使用自定义的表名，就通过这个属性指定，比如：

table_name='my_owner_table'

• db_tablespace

有些数据库有数据库表空间，比如Oracle。你可以通过db_tablespace来指定这个模型对应的数据库表放在哪个数据库表空间。

• get_latest_by

由于Django的管理方法中有个lastest()方法，就是得到最近一行记录。如果你的数据模型中有 DateField 或 DateTimeField 类型的字段，你可以通过这个选项来指定lastest()是按照哪个字段进行选取的。

• managed

由于Django会自动根据模型类生成映射的数据库表，如果你不希望Django这么做，可以把managed的值设置为False。

• order_with_respect_to

 

这个选项一般用于多对多的关系中，它指向一个关联对象。就是说关联对象找到这个对象后它是经过排序的。指定这个属性后你会得到一个get_XXX_order()和set_XXX_order（）的方法,通过它们你可以设置或者回去排序的对象。

• ordering

这个字段是告诉Django模型对象返回的记录结果集是按照哪个字段排序的。比如下面的代码：

ordering=['order_date'] # 按订单升序排列
ordering=['-order_date'] # 按订单降序排列，-表示降序
ordering=['?order_date'] # 随机排序，？表示随机

• permissions

permissions主要是为了在Django Admin管理模块下使用的，如果你设置了这个属性可以让指定的方法权限描述更清晰可读。

• proxy

这是为了实现代理模型使用的，这里先不讲随后的文章介绍。

• unique_together

unique_together这个选项用于：当你需要通过两个字段保持唯一性时使用。比如假设你希望，一个Person的FirstName和LastName两者的组合必须是唯一的，那么需要这样设置：

unique_together = (("first_name", "last_name"),)

• verbose_name

verbose_name的意思很简单，就是给你的模型类起一个更可读的名字：

verbose_name = "pizza"

• verbose_name_plural

这个选项是指定，模型的复数形式是什么，比如：

verbose_name_plural = "stories"

如果不指定Django会自动在模型名称后加一个’s’

1. class Register(models.Model):
2. id = models.IntegerField(primary_key = True, db_column="ID")
3. mid = models.IntegerField(db_column = "MID")
4. name = models.CharField(max_length = 10 , db_column = "NAME")
5. nickName = models.CharField(max_length = 100 ,db_column = "NICK_NAME")
6. slo = models.CharField(max_length = 50, db_column = "SLOGAN")
7. status = models.SmallIntegerField(db_column = "STATUS")
8. cnt = models.IntegerField(db_column = "CNT")
9. createdDate = models.DateTimeField(db_column = "CREATED_DATE")
10. class Meta:
11. db_table = "A111208FACTIONVOTETOP10_REGISTER"
12. managed = False

 

30W年薪的人工智能工程师只是“白菜价”？

人工智能技术向前发展，也必然会出现一些岗位被人工智能取代，但我们相信，随着人工智能的发展，会有更多的新的、属于未来的工作岗位出现，是社会发展的必然产物，我们能做的也许只能是与时俱进了

 

 

######

https://blog.csdn.net/qq_25730711/article/details/60327344

 

https://blog.csdn.net/zhaobig/article/details/78033534

https://blog.csdn.net/qingche456/article/details/55261528

django-关于manage.py migrate无效的问题

问题描述：
已有的model，修改之后，想重新建模，于是将migrations文件夹中除__init__.py之外其他文件都删掉，再次执行以下步骤python manage.py makemigrations确认成功，执行python manage.py migrate，提示No migrations to apply. 表示一脸懵逼。再次修改，指定表名，再次尝试，发现问题依旧，表示二脸懵逼

排查过程
python manage.py dbshell 进到数据库里面，查看是否表已存在
结果：表不存在
检查migrations文件
结果：文件没问题
百度 google 各种搜，乱投医，各种尝试
解决方案
python manage.py dbshell 进到数据库中，执行delete from django_migrations where app='your_appname';
python manage.py makemigrations(若migrations文件未删除，可不执行这一步)
python manage.py migrate 好啦，大功告成
原因分析
查看django_migrations表结构
建表语句：
CREATE TABLE "django_migrations" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "app" varchar(255) NOT NULL, "name" varchar(255) NOT NULL, "applied" datetime NOT NULL);
原因
造成多次应用migrations失败的原因是，当前model是修改过的，原来的migrations已经被我删除，但是，重新生成的migrations使用递增整数记名，所以，在django_migrations表中0001，0002等前面几个数字的文件都已被记录，在Django看来，被记录了就相当于已应用，所以，会出现刚开始的No migrations to apply.
避免方案
有强迫症删除migrations文件的同学(比如我)，请同时到数据库中删除相应记录
没有强迫症的同学，可以继续生成新的migrations，旧的就不必理会了
题外话
执行python manage.py migrate之后，可以使用python manage.py sqlmigrate appname migrations_num(例如python manage.py sqlmigrate user 0002)查看当前migrations文件对应的sql语句。
另外，在使用上述命令查看0002文件的sql语句时发现，django会新建一个表user_new，然后插入user表中的数据，再把user表删掉，再把user_new重命名为user。所以，修改model的时候，不必担心原有数据会丢失。
---------------------
作者：Jessie-via
来源：CSDN
原文：https://blog.csdn.net/qq_25730711/article/details/60327344
版权声明：本文为博主原创文章，转载请附上博文链接！

###########sample

django-关于manage.py migrate无效的问题 不能创建新表

8.Exception Value: (1146, "Table 'db_monitor.tab_alarm_info' doesn't exist") ，

原因是因为参数managed = False 控制的，屏蔽这个参数即可

1

fram/model.py

managed = False
to
# managed = False

2.
delete 001_initial.py

3.
mysql> delete from django_migrations where app='frame';
commit;

4.
--create 0001_initial.py file
python2 manage.py makemigrations

5.

--create table in database
python2 manage.py migrate