命令行方式運行Python腳本

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

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

chmod a+x script.py

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

./script.py <arguments>

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

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

從現(xiàn)在開始，在Linux/OS X上的語句簡潔。如果你使用Windows系統(tǒng)請記得轉(zhuǎn)換語句。 
 
在Flask使用數(shù)據(jù)庫

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

ORMs允許數(shù)據(jù)庫程序用對象的方式替代表和SQL語句。面向?qū)ο蟮牟僮鞅籓RM轉(zhuǎn)化為數(shù)據(jù)庫命令。這樣就意味著，不用sql語句，讓Flask-SQLAlchemy為我們執(zhí)行sql語句。
 
遷移

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

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

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

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

配置

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

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

import os
basedir = os.path.abspath(os.path.dirname(__file__))
 
SQLALCHEMY_DATABASE_URI = 'sqlite:///' + os.path.join(basedir, 'app.db')
SQLALCHEMY_MIGRATE_REPO = os.path.join(basedir, 'db_repository')

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

SQLALCHEMY_MIGRATE_REPO 是用來存儲SQLAlchemy-migrate數(shù)據(jù)庫文件的文件夾。

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

from flask import Flask
from flask.ext.sqlalchemy import SQLAlchemy
 
app = Flask(__name__)
app.config.from_object('config')
db = SQLAlchemy(app)
 
from app import views, models

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

數(shù)據(jù)庫模型

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

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

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

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

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

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

from app import db
 
ROLE_USER = 0
ROLE_ADMIN = 1
 
class User(db.Model):
  id = db.Column(db.Integer, primary_key = True)
  nickname = db.Column(db.String(64), index = True, unique = True)
  email = db.Column(db.String(120), index = True, unique = True)
  role = db.Column(db.SmallInteger, default = ROLE_USER)
 
  def __repr__(self):
    return '<User %r>' % (self.nickname)

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

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

創(chuàng)建數(shù)據(jù)庫

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

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

#!flask/bin/python
from migrate.versioning import api
from config import SQLALCHEMY_DATABASE_URI
from config import SQLALCHEMY_MIGRATE_REPO
from app import db
import os.path
db.create_all()
if not os.path.exists(SQLALCHEMY_MIGRATE_REPO):
  api.create(SQLALCHEMY_MIGRATE_REPO, 'database repository')
  api.version_control(SQLALCHEMY_DATABASE_URI, SQLALCHEMY_MIGRATE_REPO)
else:
  api.version_control(SQLALCHEMY_DATABASE_URI, SQLALCHEMY_MIGRATE_REPO, api.version(SQLALCHEMY_MIGRATE_REPO))

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

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

./db_create.py

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

第一次遷移

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

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

#!flask/bin/python
import imp
from migrate.versioning import api
from app import db
from config import SQLALCHEMY_DATABASE_URI
from config import SQLALCHEMY_MIGRATE_REPO
migration = SQLALCHEMY_MIGRATE_REPO + '/versions/%03d_migration.py' % (api.db_version(SQLALCHEMY_DATABASE_URI, SQLALCHEMY_MIGRATE_REPO) + 1)
tmp_module = imp.new_module('old_model')
old_model = api.create_model(SQLALCHEMY_DATABASE_URI, SQLALCHEMY_MIGRATE_REPO)
exec old_model in tmp_module.__dict__
script = api.make_update_script_for_model(SQLALCHEMY_DATABASE_URI, SQLALCHEMY_MIGRATE_REPO, tmp_module.meta, db.metadata)
open(migration, "wt").write(script)
a = api.upgrade(SQLALCHEMY_DATABASE_URI, SQLALCHEMY_MIGRATE_REPO)
print 'New migration saved as ' + migration
print 'Current database version: ' + str(api.db_version(SQLALCHEMY_DATABASE_URI, SQLALCHEMY_MIGRATE_REPO))

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

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

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

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

./db_migrate.py

腳本將打印出以下信息:

New migration saved as db_repository/versions/001_migration.py Current database version: 1

這個腳本信息顯示了遷移腳本的存放位置，還有當前數(shù)據(jù)庫的版本號?？諗?shù)據(jù)庫的版本號是0，當我們導入users信息后版本號變?yōu)?.

數(shù)據(jù)庫的升級和回滾

現(xiàn)在你可能想知道為什么我們要做額外的工作來做數(shù)據(jù)庫的遷移記錄。

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

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

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

#!flask/bin/python
from migrate.versioning import api
from config import SQLALCHEMY_DATABASE_URI
from config import SQLALCHEMY_MIGRATE_REPO
api.upgrade(SQLALCHEMY_DATABASE_URI, SQLALCHEMY_MIGRATE_REPO)
print 'Current database version: ' + str(api.db_version(SQLALCHEMY_DATABASE_URI, SQLALCHEMY_MIGRATE_REPO))

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

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

#!flask/bin/python
from migrate.versioning import api
from config import SQLALCHEMY_DATABASE_URI
from config import SQLALCHEMY_MIGRATE_REPO
v = api.db_version(SQLALCHEMY_DATABASE_URI, SQLALCHEMY_MIGRATE_REPO)
api.downgrade(SQLALCHEMY_DATABASE_URI, SQLALCHEMY_MIGRATE_REPO, v - 1)
print 'Current database version: ' + str(api.db_version(SQLALCHEMY_DATABASE_URI, SQLALCHEMY_MIGRATE_REPO))

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

數(shù)據(jù)庫關聯(lián)

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

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

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

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

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

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

from app import db
 
ROLE_USER = 0
ROLE_ADMIN = 1
 
class User(db.Model):
  id = db.Column(db.Integer, primary_key = True)
  nickname = db.Column(db.String(64), unique = True)
  email = db.Column(db.String(120), unique = True)
  role = db.Column(db.SmallInteger, default = ROLE_USER)
  posts = db.relationship('Post', backref = 'author', lazy = 'dynamic')
 
  def __repr__(self):
    return '<User %r>' % (self.nickname)
 
class Post(db.Model):
  id = db.Column(db.Integer, primary_key = True)
  body = db.Column(db.String(140))
  timestamp = db.Column(db.DateTime)
  user_id = db.Column(db.Integer, db.ForeignKey('user.id'))
 
  def __repr__(self):
    return '<Post %r>' % (self.body)

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

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

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

./db_migrate.py

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

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

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

應用實踐

我們已經(jīng)花了大量的時間在數(shù)據(jù)庫定義上，但是我們?nèi)匀粵]有看到他是如何工作的，因為我們的應用程序里沒有任何的數(shù)據(jù)相關的編碼，接下來我們將在Python解釋器里使用我們的嶄新數(shù)據(jù)庫吧。

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

Windows下:

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

>>> from app import db, models >>>

這樣我們的數(shù)據(jù)庫模塊和models就被加載到了內(nèi)存里.

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

>>> u = models.User(nickname='john', email='john@email.com', role=models.ROLE_USER)
>>> db.session.add(u)
>>> db.session.commit()
>>>

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

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

>>> u = models.User(nickname='susan', email='susan@email.com', role=models.ROLE_USER)
>>> db.session.add(u)
>>> db.session.commit()
>>>

現(xiàn)在我們可以查詢出用戶信息：
 

>>> users = models.User.query.all()
>>> print users
[<User u'john'>, <User u'susan'>]
>>> for u in users:
...   print u.id,u.nickname
...
1 john
2 susan
>>>

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

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

>>> u = models.User.query.get(1)
>>> print u
<User u'john'>
>>>

現(xiàn)在讓我們添加一條微博信息：
 

>>> import datetime
>>> u = models.User.query.get(1)
>>> p = models.Post(body='my first post!', timestamp=datetime.datetime.utcnow(), author=u)
>>> db.session.add(p)
>>> db.session.commit()

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

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

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

# get all posts from a user
>>> u = models.User.query.get(1)
>>> print u
<User u'john'>
>>> posts = u.posts.all()
>>> print posts
[<Post u'my first post!'>]
 
# obtain author of each post
>>> for p in posts:
...   print p.id,p.author.nickname,p.body
...
1 john my first post!
 
# a user that has no posts
>>> u = models.User.query.get(2)
>>> print u
<User u'susan'>
>>> print u.posts.all()
[]
 
# get all users in reverse alphabetical order
>>> print models.User.query.order_by('nickname desc').all()
[<User u'susan'>, <User u'john'>]
>>>

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

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

>>> users = models.User.query.all()
>>> for u in users:
...   db.session.delete(u)
...
>>> posts = models.Post.query.all()
>>> for p in posts:
...   db.session.delete(p)
...
>>> db.session.commit()
>>>

結束語

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

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

最新評論