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’

 

 

Java程式碼  

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.       
11.     class Meta:  
12.         db_table = "A111208FACTIONVOTETOP10_REGISTER"  
13.         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