命令行方式运行Python脚本
在这个章节中,我们将写一些简单的数据库管理脚本。在此之前让我们来复习一下如何通过命令行方式执行Python脚本.
如果Linux 或者OS X的操作系统,需要有执行脚本的权限。例如:
chmod a+x script.py
该脚本有个指向使用解释器的命令行。再脚本赋予执行权限后就可以通过命令行执行,就像这样: like this:
./script.py <arguments>
然而,在Windows系统上这样做是不行的,你必须提供Python解释器作为必选参数,如:
复制代码 代码如下:
flask/Scripts/python script.py
为了避免Python解释器路径输入出错,你可以将你的文件夹microoblog/flask/Scripts添加到系统路径,确保能正常显示Python解释器。
从现在开始,在Linux/OS X上的语句简洁。如果你使用Windows系统请记得转换语句。
在Flask使用数据库
我们将使用Flask-SQLAlchemy 的扩展来管理数据库。由SQLAlchemy项目提供的,已封装了关系对象映射(ORM)的一个插件。
ORMs允许数据库程序用对象的方式替代表和SQL语句。面向对象的操作被ORM转化为数据库命令。这样就意味着,不用sql语句,让Flask-SQLAlchemy为我们执行sql语句。
迁移
大多数数据库教程都覆盖了创建和使用一个数据库的方法,但是没有充分解决当应用程序扩展时数据库更新的问题。通常,你会删除旧的数据库,然后再创建一个新的数据库来达到更新的效果,这样就丢失了所有的数据。如果这些数据创建起来很费劲,那么我们不得不写导入导出的脚本了。
幸运的是,我们有了更好的方案.
我们现在可以使用SQLAlchemy-migrate做数据库迁移的更新了,虽然它增加了数据库启动时的负担,但这点小小的代价还是值得的,毕竟我们不用担心手动迁移数据库的问题了。
理论学习完毕,我们开始吧!
配置
我们的小程序使用sqlite数据库。sqlite是小程序数据库的最佳选择,一个可以以单文件存储的数据库。
在我们的配置文件中添加新的配置项 (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必需的扩展。这是我们的数据库文件的路径。
SQLALCHEMY_MIGRATE_REPO 是用来存储SQLAlchemy-migrate数据库文件的文件夹。
最后,初始化应用的时候也需要初始化数据库。这里是升级后的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个地方。我们现在开始创建数据库的adb对象,引用新的模块。马上来写这个模块。
数据库模型
我们在数据库存储的数据通过数据库model层被映射为一些类里面的对象,ORM层将根据类对象映射到数据库对应的字段.
让我们来创建个映射到users的model。使用WWW SQL Designer工具,我们创建了代表users表的一个图标:
id字段通常作为主键的形式用在所有的models里面,每个在数据库中的user都有一个指定的唯一id值。幸运的是,这些都是自动的,我们只需要提供一个id字段。
nickname和email字段被定义为string类型,他们的长度也已经被指定,这样可以节省数据库存储空间。
role字段被定义为integer类型,我们用来标识users是admins还是其他类型。
现在我们已经明确了users表的结构,接下来转换为编码的工作将相当简单了(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类把我们刚刚创建的几个字段定义为类变量。字段使用db.Column类创建实例,字段的类型作为参数,另外还提供一些其他可选参数。例如,标识字段唯一性和索引的参数.
repr方法告诉Python如何打印class对象,方便我们调试使用。
创建数据库
把配置和model放到正确的目录位置,现在我们创建数据库文件。SQLAlchemy-migrate包自带命令行工具和APIs来创建数据库,这样的方式可以方便以后更新。但是我觉得使用这个命令行工具有些别扭,所以我自己写了个python脚本来调用迁移的APIs.
这里有个创建数据库的脚本 (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目录下就能正常使用了。
创建数据库你只需要运行下面的一条命令(注意windows下稍微有些不同):
./db_create.py
运行这条命令之后,你就创建了一个新的app.db文件。这是个支持迁移的空sqlite数据库,同时也会生成一个带有几个文件的db_repository目录,这是SQLAlchemy-migrate存储数据库文件的地方,注意如果数据库已存在它就不会再重新生成了。这将帮助我们在丢失了现有的数据库后,再次自动创建出来。.
第一次迁移
既然我们已经定义好了model,也把它和数据库做了关联,接下来我们来初次尝试下做一个改变应用数据库结构的一次迁移,这将帮助我们从一个空的数据库变成一个可以存储users信息的数据库。
做一个迁移我使用另一个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通过对比数据库的结构(从app.db文件读取)和models结构(从app/models.py文件读取)的方式来创建迁移任务,两者之间的差异将作为一个迁移脚本记录在迁移库中,迁移脚本知道如何应用或者撤销一次迁移,所以它可以方便的升级或者降级一个数据库的格式。
虽然我使用上面的脚本自动生成迁移时没遇到什么问题,但有时候真的很难决定数据库旧格式和新格式究竟有啥改变。为了让SQLAlchemy-migrate更容易确定数据库的改变,我从来不给现有字段重命名,限制了添加删除models、字段,或者对现有字段的类型修改。我总是检查下生成的迁移脚本是否正确。
不用多讲,在你试图迁移数据库前必须做好备份,以防出现问题。不要在生产用的数据库上运行第一次使用的脚本,先在开发用的数据库上运行下。
继续前进,记录下我们的迁移:
./db_migrate.py
脚本将打印出以下信息:
New migration saved as db_repository/versions/001_migration.py Current database version: 1
这个脚本信息显示了迁移脚本的存放位置,还有当前数据库的版本号。空数据库的版本号是0,当我们导入users信息后版本号变为1.
数据库的升级和回滚
现在你可能想知道为什么我们要做额外的工作来做数据库的迁移记录。
试想一下,你有个应用在开发机器上,同时服务器上也有一个复制的应用正在运行。
比方说,在你产品的下个版本你的models层作了修改,比如增加了一个新表。没有迁移文件的话,你需要同时解决在开发机和服务器上数据库格式修改的问题,这将是个很大的工作量。
如果你已经有了一个支持迁移的数据库,那么当你向生产服务器发布新的应用版本时,你只需要记录下新的迁移记录,把迁移脚本拷贝到你的生产服务器上,然后运行一个简单的应用改变脚本就行。数据库的升级可以使用下面的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))
当你运行上面的脚本时,数据库将升级到最新版本,并通过脚本将改变信息存储到数据库中。
把数据库回滚到旧的格式,这是不常见的一个方式,但以防万一,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))
这个脚本将回滚数据库的一个版本,你可以通过运行多次的方式向前回滚多个版本。
数据库关联
关系型数据库最擅长存储数据之间的关系。假如用户会写一篇微博,用户的信息被存储在users表中,微博存储在post表中。记录谁写的微博最有效的方式是建立两条数据之间的关联.
一旦用户和微博的关系表建立之后,我们有两种查询方式可以使用。.最琐碎的一个就是当你看到一篇微博,你想知道是哪个用户写的。更复杂的一个是反向的查询,如果你知道一个用户,你想了解下他写的全部微博。Flask-SQLAlchemy将给我们提供对两种方式查询的帮助。
让我们对数据做一下扩展来存储微博信息,这样我们就能看到对应的关系了。我们回到我们使用的数据库设计工具来创建个posts表:
posts表包含一个必须的id,微博的内容body,还有一个时间戳。没有什么新东西,但是user_id字段值得解释下。
我们想建立用户和他们写的微博之间的关联,这种方法就是通过添加一个包含用户id的字段来标识谁写的微博,这个id叫做外键。我们的数据库设计工具也显示了外键作为一个外键和id字段指向表的连接。这种关联叫做一对多关联,也就是一个用户可以写多篇文章。
让我们修改下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会知道这个字段将会和用户做关联。
注意我们还在User类中添加了一个新字段命名为posts,它被定义成一个db.relationship字段,这个字段并非是数据库中实际存在的字段,所以它不在我们的数据库图表中。对于一对多的关联db.relationship字段通常只需要在一边定义。根据这个关联我们可以获取到用户的微博列表。db.relationship的第一个参数表示"many"一方的类名。backref参数定义了一个字段将"many"类的对象指回到"one"对象,就我们而言,我们可以使用psot.author获取到User实例创建一个微博。如果理解不了不要担心,在文章的后面我们将通过一个例子来解释。
让我们用另外一个迁移文件记录下这次的改变。简单运行下面脚本:
./db_migrate.py
运行脚本后将得到如下输出:
New migration saved as db_repository/versions/002_migration.py Current database version: 2
我们没必要每次都用一个独立的迁移文件来记录数据库model层的小变化,一个迁移文件通常只是记录一个发布版本的改变。接下来更重要的事情是我们需要了解下迁移系统的工作原理。
应用实践
我们已经花了大量的时间在数据库定义上,但是我们仍然没有看到他是如何工作的,因为我们的应用程序里没有任何的数据相关的编码,接下来我们将在Python解释器里使用我们的崭新数据库吧。
继续前进,启动Python。 在 Linux 或者 OS X:
复制代码 代码如下:
flask/bin/python
Windows下:
复制代码 代码如下:
flask/Scripts/python
当你在Python命令行提示符中输入下面信息:
>>> from app import db, models >>>
这样我们的数据库模块和models就被加载到了内存里.
让我们来创建个新用户:
>>> u = models.User(nickname='john', email='john@email.com', role=models.ROLE_USER)
>>> db.session.add(u)
>>> db.session.commit()
>>>
在同一个会话环境下更改数据库,多次的修改可以积累到一个会话中最后通过调用一个db.session.commit()命令提交,提交同时也保证了原子性。如果在会话中出现了错误,会调用db.session.rollback()把数据库回滚到会话之前的状态。如果调用的既不是提交也不是回滚,那么系统会默认回滚这个会话。Sessions(会话)保证了数据库的数据一致性。
让我们来添加另外一个用户:
>>> u = models.User(nickname='susan', email='susan@email.com', role=models.ROLE_USER)
>>> db.session.add(u)
>>> db.session.commit()
>>>
现在我们可以查询出用户信息:
>>> 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查询函数,在所有的model类中都可以使用这个函数。注意id是如何自动生成的。
还有另外一种方式来查询,如果我们知道了用户的id,我们可以使用下面的方式查找用户信息:
>>> u = models.User.query.get(1)
>>> print u
<User u'john'>
>>>
现在让我们添加一条微博信息:
>>> 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时区,所有的存储在数据库里的时间将是UTC格式,用户可能在世界各地写微博,因此我们需要使用统一的时间单位。在以后的教程中我们将学习如何在用户本地时区使用这些时间。
你也许注意到我们没有在Post类中设置user_id字段,取而代之的是把用户对象存储到了author字段。auhtor字段是个通过Flask-SQLAlchemy添加的虚拟字段用来建立关联关系的,我们之前已经定义好了这个名字,参照:model中的db.relationship中backref参数。通过这些信息,ORM层就能知道如何取到user_id。
要完成这个会话,让我们来看看更多可做的数据库查询:
# 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'>]
>>>
要了解更多的数据库查询选项,最好的方式就是去看 Flask-SQLAlchemy 的文档。
在结束会话之前,我们把之前创建的测试用户和文章删除掉,就可以在接下来的章节,从一个干净的数据库开始:
>>> 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()
>>>
结束语
这一长篇新手入门,我们了解到了数据库的基本操作,但我们还没有将数据库关联到程序中。在下一个章节中我们通过用户登录系统来练习所学的数据库操作。
在此同时,如果你还没开始写程序,你需要下载当前文件 microblog-0.4.zip.注意,zip文件中没有包括数据库,但是已经有存储脚本。用db_create.py创建一个新的数据库,用db_upgrade.py把你的数据库升级到最新版本。
京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而,京东官方通过微博发言人发布的消息澄清了这些传言,称这些言论纯属虚假信息和蓄意捏造。
日前,据博主“@超能数码君老周”爆料,国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。
据报道,荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦(ASML)CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。
今年早些时候,抖音悄然上线了一款名为“青桃”的 App,Slogan 为“看见你的热爱”,根据应用介绍可知,“青桃”是一个属于年轻人的兴趣知识视频平台,由抖音官方出品的中长视频关联版本,整体风格有些类似B站。
日前,威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”,同时,他发文表示:中国汽车普及率低于非洲国家尼日利亚,每百户家庭仅17户有车。意大利世界排名第一,每十户中九户有车。
近日,一项新的研究发现,维生素 C 和 E 等抗氧化剂会激活一种机制,刺激癌症肿瘤中新血管的生长,帮助它们生长和扩散。
据媒体援引消息人士报道,苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后,3D系统一度大涨超10%,不过截至周三收盘,该股涨幅回落至2%以内。
9月2日,坐拥千万粉丝的网红主播“秀才”账号被封禁,在社交媒体平台上引发热议。平台相关负责人表示,“秀才”账号违反平台相关规定,已封禁。据知情人士透露,秀才近期被举报存在违法行为,这可能是他被封禁的部分原因。据悉,“秀才”年龄39岁,是安徽省亳州市蒙城县人,抖音网红,粉丝数量超1200万。他曾被称为“中老年...
9月3日消息,亚马逊的一些股东,包括持有该公司股票的一家养老基金,日前对亚马逊、其创始人贝索斯和其董事会提起诉讼,指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。
据消息,为推广自家应用,苹果现推出了一个名为“Apps by Apple”的网站,展示了苹果为旗下产品(如 iPhone、iPad、Apple Watch、Mac 和 Apple TV)开发的各种应用程序。
特斯拉本周在美国大幅下调Model S和X售价,引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金(Future Fund)管理合伙人加里·布莱克发帖称,降价是一种“短期麻醉剂”,会让潜在客户等待进一步降价。
据外媒9月2日报道,荷兰半导体设备制造商阿斯麦称,尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效,但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。
近日,根据美国证券交易委员会的文件显示,苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元(约 4.65 亿元人民币)。用于在 2023-2025 年期间,发射卫星,进一步扩展苹果 iPhone 系列的 SOS 卫星服务。
据报道,马斯克旗下社交平台𝕏(推特)日前调整了隐私政策,允许 𝕏 使用用户发布的信息来训练其人工智能(AI)模型。新的隐私政策将于 9 月 29 日生效。新政策规定,𝕏可能会使用所收集到的平台信息和公开可用的信息,来帮助训练 𝕏 的机器学习或人工智能模型。
9月2日,荣耀CEO赵明在采访中谈及华为手机回归时表示,替老同事们高兴,觉得手机行业,由于华为的回归,让竞争充满了更多的可能性和更多的魅力,对行业来说也是件好事。
《自然》30日发表的一篇论文报道了一个名为Swift的人工智能(AI)系统,该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。
近日,非营利组织纽约真菌学会(NYMS)发出警告,表示亚马逊为代表的电商平台上,充斥着各种AI生成的蘑菇觅食科普书籍,其中存在诸多错误。
社交媒体平台𝕏(原推特)新隐私政策提到:“在您同意的情况下,我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”
2023年德国柏林消费电子展上,各大企业都带来了最新的理念和产品,而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。
罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品,具体内容为:“以我对我‘子公司’的了解,我认为 iPhone 15 跟 iPhone 14 不会有什么区别的,除了序(列)号变了,这个‘不要脸’的东西,这个‘臭厨子’。