Python的Flask框架與數據庫連接的教程

命令行方式運行Python腳本

在這個章節(jié)中，我們將寫一些簡單的數據庫管理腳本。在此之前讓我們來復習一下如何通過命令行方式執(zhí)行Python腳本.

如果Linux 或者OS X的操作系統，需要有執(zhí)行腳本的權限。例如：

該腳本有個指向使用解釋器的命令行。再腳本賦予執(zhí)行權限后就可以通過命令行執(zhí)行，就像這樣： like this:

然而，在Windows系統上這樣做是不行的，你必須提供Python解釋器作為必選參數，如：

為了避免Python解釋器路徑輸入出錯，你可以將你的文件夾microoblog/flask/Scripts添加到系統路徑，確保能正常顯示Python解釋器。

從現在開始，在Linux/OS X上的語句簡潔。如果你使用Windows系統請記得轉換語句。 
  在Flask使用數據庫

我們將使用Flask-SQLAlchemy 的擴展來管理數據庫。由SQLAlchemy項目提供的，已封裝了關系對象映射（ORM）的一個插件。

ORMs允許數據庫程序用對象的方式替代表和SQL語句。面向對象的操作被ORM轉化為數據庫命令。這樣就意味著，不用sql語句，讓Flask-SQLAlchemy為我們執(zhí)行sql語句。
  遷移

大多數數據庫教程都覆蓋了創(chuàng)建和使用一個數據庫的方法，但是沒有充分解決當應用程序擴展時數據庫更新的問題。通常，你會刪除舊的數據庫，然后再創(chuàng)建一個新的數據庫來達到更新的效果，這樣就丟失了所有的數據。如果這些數據創(chuàng)建起來很費勁，那么我們不得不寫導入導出的腳本了。

幸運的是，我們有了更好的方案.

我們現在可以使用SQLAlchemy-migrate做數據庫遷移的更新了，雖然它增加了數據庫啟動時的負擔，但這點小小的代價還是值得的，畢竟我們不用擔心手動遷移數據庫的問題了。

理論學習完畢，我們開始吧！

配置

我們的小程序使用sqlite數據庫。sqlite是小程序數據庫的最佳選擇，一個可以以單文件存儲的數據庫。

在我們的配置文件中添加新的配置項 (fileconfig.py):

SQLALCHEMY_DATABASE_URI是the Flask-SQLAlchemy必需的擴展。這是我們的數據庫文件的路徑。

SQLALCHEMY_MIGRATE_REPO 是用來存儲SQLAlchemy-migrate數據庫文件的文件夾。

最后，初始化應用的時候也需要初始化數據庫。這里是升級后的init文件(fileapp/__init)： 

注意生成的腳本已改動2個地方。我們現在開始創(chuàng)建數據庫的adb對象，引用新的模塊。馬上來寫這個模塊。

數據庫模型

我們在數據庫存儲的數據通過數據庫model層被映射為一些類里面的對象，ORM層將根據類對象映射到數據庫對應的字段.

讓我們來創(chuàng)建個映射到users的model。使用WWW SQL Designer工具，我們創(chuàng)建了代表users表的一個圖標:

id字段通常作為主鍵的形式用在所有的models里面，每個在數據庫中的user都有一個指定的唯一id值。幸運的是，這些都是自動的，我們只需要提供一個id字段。

nickname和email字段被定義為string類型，他們的長度也已經被指定，這樣可以節(jié)省數據庫存儲空間。

role字段被定義為integer類型，我們用來標識users是admins還是其他類型。

現在我們已經明確了users表的結構，接下來轉換為編碼的工作將相當簡單了(fileapp/models.py)：

User類把我們剛剛創(chuàng)建的幾個字段定義為類變量。字段使用db.Column類創(chuàng)建實例，字段的類型作為參數，另外還提供一些其他可選參數。例如，標識字段唯一性和索引的參數.

__repr__方法告訴Python如何打印class對象，方便我們調試使用。

創(chuàng)建數據庫

把配置和model放到正確的目錄位置，現在我們創(chuàng)建數據庫文件。SQLAlchemy-migrate包自帶命令行工具和APIs來創(chuàng)建數據庫，這樣的方式可以方便以后更新。但是我覺得使用這個命令行工具有些別扭，所以我自己寫了個python腳本來調用遷移的APIs.

這里有個創(chuàng)建數據庫的腳本 (filedb_create.py):

注意這個腳本是完全通用的，所有的應用路徑名都是從配置文件讀取的。當你用在自己的項目時，你可以把腳本拷貝到你app`s目錄下就能正常使用了。

創(chuàng)建數據庫你只需要運行下面的一條命令（注意windows下稍微有些不同）:

運行這條命令之后，你就創(chuàng)建了一個新的app.db文件。這是個支持遷移的空sqlite數據庫，同時也會生成一個帶有幾個文件的db_repository目錄，這是SQLAlchemy-migrate存儲數據庫文件的地方，注意如果數據庫已存在它就不會再重新生成了。這將幫助我們在丟失了現有的數據庫后，再次自動創(chuàng)建出來。.

第一次遷移

既然我們已經定義好了model，也把它和數據庫做了關聯，接下來我們來初次嘗試下做一個改變應用數據庫結構的一次遷移，這將幫助我們從一個空的數據庫變成一個可以存儲users信息的數據庫。

做一個遷移我使用另一個Python小助手腳本 (filedb_migrate.py):

這個腳本看起來很復雜，其實做的東西真不多。SQLAlchemy-migrate通過對比數據庫的結構（從app.db文件讀?。┖蚼odels結構（從app/models.py文件讀取）的方式來創(chuàng)建遷移任務，兩者之間的差異將作為一個遷移腳本記錄在遷移庫中，遷移腳本知道如何應用或者撤銷一次遷移，所以它可以方便的升級或者降級一個數據庫的格式。

雖然我使用上面的腳本自動生成遷移時沒遇到什么問題，但有時候真的很難決定數據庫舊格式和新格式究竟有啥改變。為了讓SQLAlchemy-migrate更容易確定數據庫的改變，我從來不給現有字段重命名，限制了添加刪除models、字段，或者對現有字段的類型修改。我總是檢查下生成的遷移腳本是否正確。

不用多講，在你試圖遷移數據庫前必須做好備份，以防出現問題。不要在生產用的數據庫上運行第一次使用的腳本，先在開發(fā)用的數據庫上運行下。

繼續(xù)前進，記錄下我們的遷移:

./db_migrate.py

腳本將打印出以下信息:    
New migration saved as db_repository/versions/001_migration.py Current database version: 1
這個腳本信息顯示了遷移腳本的存放位置，還有當前數據庫的版本號?？諗祿斓陌姹咎柺?，當我們導入users信息后版本號變?yōu)?.

數據庫的升級和回滾

現在你可能想知道為什么我們要做額外的工作來做數據庫的遷移記錄。

試想一下，你有個應用在開發(fā)機器上，同時服務器上也有一個復制的應用正在運行。

比方說，在你產品的下個版本你的models層作了修改，比如增加了一個新表。沒有遷移文件的話，你需要同時解決在開發(fā)機和服務器上數據庫格式修改的問題，這將是個很大的工作量。

如果你已經有了一個支持遷移的數據庫，那么當你向生產服務器發(fā)布新的應用版本時，你只需要記錄下新的遷移記錄，把遷移腳本拷貝到你的生產服務器上，然后運行一個簡單的應用改變腳本就行。數據庫的升級可以使用下面的Python腳本（filedb_upgrade.py）：

當你運行上面的腳本時，數據庫將升級到最新版本，并通過腳本將改變信息存儲到數據庫中。

把數據庫回滾到舊的格式，這是不常見的一個方式，但以防萬一，SQLAlchemy-migrate也很好的支持(filedb_downgrade.py):

這個腳本將回滾數據庫的一個版本，你可以通過運行多次的方式向前回滾多個版本。

數據庫關聯

關系型數據庫最擅長存儲數據之間的關系。假如用戶會寫一篇微博，用戶的信息被存儲在users表中，微博存儲在post表中。記錄誰寫的微博最有效的方式是建立兩條數據之間的關聯.

一旦用戶和微博的關系表建立之后，我們有兩種查詢方式可以使用。.最瑣碎的一個就是當你看到一篇微博，你想知道是哪個用戶寫的。更復雜的一個是反向的查詢，如果你知道一個用戶，你想了解下他寫的全部微博。Flask-SQLAlchemy將給我們提供對兩種方式查詢的幫助。

讓我們對數據做一下擴展來存儲微博信息，這樣我們就能看到對應的關系了。我們回到我們使用的數據庫設計工具來創(chuàng)建個posts表： 

 posts表包含一個必須的id,微博的內容body，還有一個時間戳。沒有什么新東西，但是user_id字段值得解釋下。

我們想建立用戶和他們寫的微博之間的關聯，這種方法就是通過添加一個包含用戶id的字段來標識誰寫的微博，這個id叫做外鍵。我們的數據庫設計工具也顯示了外鍵作為一個外鍵和id字段指向表的連接。這種關聯叫做一對多關聯，也就是一個用戶可以寫多篇文章。

讓我們修改下models來響應這些變化 (app/models.py):

我們增加了一個表示用戶寫的微博的Post類，user_id字段在Post類中被初始化指定為一個外鍵，因此Flask-SQLAlchemy會知道這個字段將會和用戶做關聯。

注意我們還在User類中添加了一個新字段命名為posts，它被定義成一個db.relationship字段，這個字段并非是數據庫中實際存在的字段，所以它不在我們的數據庫圖表中。對于一對多的關聯db.relationship字段通常只需要在一邊定義。根據這個關聯我們可以獲取到用戶的微博列表。db.relationship的第一個參數表示“many”一方的類名。backref參數定義了一個字段將"many"類的對象指回到"one"對象，就我們而言，我們可以使用psot.author獲取到User實例創(chuàng)建一個微博。如果理解不了不要擔心，在文章的后面我們將通過一個例子來解釋。

讓我們用另外一個遷移文件記錄下這次的改變。簡單運行下面腳本：

./db_migrate.py

運行腳本后將得到如下輸出：   

New migration saved as db_repository/versions/002_migration.py Current database version: 2

我們沒必要每次都用一個獨立的遷移文件來記錄數據庫model層的小變化，一個遷移文件通常只是記錄一個發(fā)布版本的改變。接下來更重要的事情是我們需要了解下遷移系統的工作原理。

應用實踐

我們已經花了大量的時間在數據庫定義上，但是我們仍然沒有看到他是如何工作的，因為我們的應用程序里沒有任何的數據相關的編碼，接下來我們將在Python解釋器里使用我們的嶄新數據庫吧。

繼續(xù)前進，啟動Python。 在 Linux 或者 OS X:

Windows下:

當你在Python命令行提示符中輸入下面信息：

這樣我們的數據庫模塊和models就被加載到了內存里.

讓我們來創(chuàng)建個新用戶：

在同一個會話環(huán)境下更改數據庫，多次的修改可以積累到一個會話中最后通過調用一個db.session.commit()命令提交，提交同時也保證了原子性。如果在會話中出現了錯誤，會調用db.session.rollback()把數據庫回滾到會話之前的狀態(tài)。如果調用的既不是提交也不是回滾，那么系統會默認回滾這個會話。Sessions（會話）保證了數據庫的數據一致性。

讓我們來添加另外一個用戶：

現在我們可以查詢出用戶信息：

此處我們使用了query查詢函數，在所有的model類中都可以使用這個函數。注意id是如何自動生成的。

還有另外一種方式來查詢，如果我們知道了用戶的id，我們可以使用下面的方式查找用戶信息：

現在讓我們添加一條微博信息：

這個地方我們把時間設置為UTC時區(qū)，所有的存儲在數據庫里的時間將是UTC格式，用戶可能在世界各地寫微博，因此我們需要使用統一的時間單位。在以后的教程中我們將學習如何在用戶本地時區(qū)使用這些時間。

你也許注意到我們沒有在Post類中設置user_id字段，取而代之的是把用戶對象存儲到了author字段。auhtor字段是個通過Flask-SQLAlchemy添加的虛擬字段用來建立關聯關系的，我們之前已經定義好了這個名字，參照：model中的db.relationship中backref參數。通過這些信息，ORM層就能知道如何取到user_id。

要完成這個會話，讓我們來看看更多可做的數據庫查詢：

要了解更多的數據庫查詢選項，最好的方式就是去看 Flask-SQLAlchemy 的文檔。

在結束會話之前，我們把之前創(chuàng)建的測試用戶和文章刪除掉，就可以在接下來的章節(jié)，從一個干凈的數據庫開始：

結束語

這一長篇新手入門，我們了解到了數據庫的基本操作，但我們還沒有將數據庫關聯到程序中。在下一個章節(jié)中我們通過用戶登錄系統來練習所學的數據庫操作。

在此同時，如果你還沒開始寫程序，你需要下載當前文件 microblog-0.4.zip.注意，zip文件中沒有包括數據庫，但是已經有存儲腳本。用db_create.py創(chuàng)建一個新的數據庫，用db_upgrade.py把你的數據庫升級到最新版本。