Django 數據表更改

Django 數據表更改

« Django 開發內容管理系統（第四天）

Django 後臺 »

 

咱們設計數據庫的時候，早期設計完後，後期會發現不完善，要對數據表進行更改，這時候就要用到本節的知識。

Django 1.7.x 和後來的版本：

Django 1.7.x 及之後的版本集成了 South 的功能，在修改models.py了後運行：

1 2	python manage.py makemigrations python manage.py migrate

這兩行命令就會對咱們的models.py 進行檢測，自動發現須要更改的，應用到數據庫中去。

Django 1.6.x 及之前：

寫過Django項目的同窗，必然會遇到這個問題：

在Django 1.6以及之前的版本中，咱們測試，當發現model要改，怎麼辦？

 

咱們修改了 models.py 以後，咱們運行：

1	python manage.py syncdb

這句話只會將咱們在 models.py 中新加的類建立相應的表。

對於原來有的，如今刪除了的類，Django 會詢問是否要刪除數據庫中已經存在的相關數據表。

 

若是在原來的類上增長字段或者刪除字段，能夠參考這個命令：

1	python manage.py sql appname

給出的SQL語句，而後本身手動到數據庫執行 SQL 。可是這樣很是容易出錯！

Django 的第三方 app South 就是專門作數據庫表結構自動遷移工做，Jacob Kaplan-Moss 曾作過一次調查，South 名列最受歡迎的第三方 app。事實上，它如今已經儼然成爲 Django 事實上的數據庫表遷移標準，不少第三方 app 都會帶 South migrations 腳本，Django 1.7 中集成了 South 的功能。

 

1, 安裝South

1	( sudo ) pip  install  South

 

2. 使用方法

一個好的程序使用起來一定是簡單的，South和它的宗旨同樣，使用簡單。只須要簡單幾步，針對已經建好model和建立完表的應用。

 

把south加入到settings.py中的INSTALL_APPS中

1 2 3 4 5 6 7 8 9 10 11 12

# Application definition INSTALLED_APPS  =  (      'django.contrib.admin' ,      'django.contrib.auth' ,      'django.contrib.contenttypes' ,      'django.contrib.sessions' ,      'django.contrib.messages' ,      'django.contrib.staticfiles' ,        'blog' ,      'south' , )

修改好後運行一次 python manage.py syncdb，Django會新建一個 south_migrationhistory 表，用來記錄數據表更改(Migration)的歷史紀錄。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

$ python manage.py syncdb Syncing... Creating tables ... Creating table south_migrationhistory Installing custom SQL ... Installing indexes ... No fixtures found.   Synced:   > django.contrib.admin   > django.contrib.auth   > django.contrib.contenttypes   > django.contrib.sessions   > django.contrib.messages   > django.contrib.staticfiles   > blog   > south   Not synced (use migrations):

 

若是要把以前建好的好比 blog 這個 app 使用 South 來管理：

1	$ python manage.py convert_to_south blog

你會發現blog文件夾中多了一個 migrations 目錄，裏面有一個 0001_initial.py 文件。

 

注：若是 blog 這個 app 以前就建立過相關的表，能夠用下面的來「僞裝」用 South 建立（僞建立，在改動 models.py 以前運行這個）

1	python manage.py migrate blog --fake

意思是這個表我之前已經建好了，用 South 只是紀一下這個建立記錄，下次 migrate 的時候沒必要再建立了。

原理就是 south_migrationhistory 中記錄下了 models.py 的修改的歷史，下次再修改時會和最近一次記錄比較，發現改變了什麼，而後生成相應的對應文件，最終執行相應的 SQL 更改原有的數據表。

 

接着，當你對 Blog.models 作任何修改後，只要執行：

1	$ python manage.py schemamigration blog --auto

South就會幫助咱們找出哪些地方作了修改，若是你新增的數據表沒有給default值，而且沒有設置null=True, south會問你一些問題，由於新增的column對於原來的舊的數據不能爲Null的話就得有一個值。順利的話，在migrations文件夾下會產生一個0002_add_mobile_column.py，可是這一步並無真正修改數據庫的表，咱們須要執行 python manage.py migrate ：

1 2 3 4 5 6

$ python manage.py migrate Running migrations  for  blog:   - Migrating forwards to 0002_add_mobile_column.   > blog:0002_add_mobile_column   - Loading initial data  for  blog. No fixtures found.

這樣所作的更改就寫入到了數據庫中了。

 

恢復到之前

South好處就是能夠隨時恢復到以前的一個版本，好比咱們想要回到最開始的那個版本：

1 2 3 4 5

> python manage.py migrate blog 0001   - Soft matched migration 0001 to 0001_initial. Running migrations  for  blog:   - Migrating backwards to just after 0001_initial.   < blog:0002_add_mobile_column

這樣就搞定了，數據庫就恢復到之前了，比你手動更改要方便太多了。