大灰狼.BLOG

New Blog New Post

2018-06-04T16:54:00+08:00

看看是不是直接就可以拿 Github Web Editor 作为博客的编辑器了。

当 SqlAlchemy 没有了外键

2016-12-27T04:00:00+08:00

目前团队习惯于不在数据库中使用外键（ForeignKey），大概是出于性能以及对脏数据的容忍度的考虑吧。这本来没什么，但是由于我们使用 SqlAlchemy 作为 ORM，就带来了一个问题：如何在不使用外键的情况下使用 SqlAlchemy 中的各种高级特性呢（如：relationship，单表继承，join表继承等）？

首先需要明确的是，上面提到的高级特性其实对外键并没有什么直接的依赖关系的，只不过如果存在外键定义的话，很多特性参数可以根据外键的定义自动配置好。

仔细查阅了 SqlAlchemy 的文档，终于整理好了各种场景下的使用方法。

后续的示例代码假设都已经执行了如下片段:

import sqlalchemy as sa
import sqlalchemy.orm as orm
from sqlalchemy.ext.declarative import declarative_base

Base = declarative_base()

One-to-Many Relationship

首先看标准的带外键的表达如下:

class Parent(Base):
    __tablename__ = 'parent'
    id = sa.Column(sa.Integer, primary_key=True)
    children = orm.relationship('Child', backref='parent')

class Child(Base):
    __tablename__ = 'child'
    id = sa.Column(sa.Integer, primary_key=True)
    parent_id = sa.Column(sa.Integer, sa.ForeignKey('parent.id'))

我们只需要标注出关联的目标，具体如何关联等信息 ORM 会根据外键帮我们自动配置好。

而如果不用外键的话，所有的关联关系都需要明确指定，代码就会复杂一些了：

class Parent(Base):
    __tablename__ = 'parent'
    id = sa.Column(sa.Integer, primary_key=True)
    children = orm.relationship(
        'Child',
        primaryjoin='Parent.id == Child.parent_id',
        foreign_keys='Child.parent_id',
        backref='parent')

class Child(Base):
    __tablename__ = 'child'
    id = sa.Column(sa.Integer, primary_key=True)
    parent_id = sa.Column(sa.Integer, sa.ForeignKey('parent.id'))

如上，需要明确指定 primary join 和 foriegn_keys 这两个参数。

One-to-One Relationship

各个只是在一对多关联的基础上添加一个 uselist=False 的参数，没啥好说的。

class Parent(Base):
    __tablename__ = 'parent'
    id = sa.Column(sa.Integer, primary_key=True)
    child = orm.relationship(
        'Child',
        primaryjoin='Parent.id == Child.parent_id',
        foreign_keys='Child.parent_id',
        uselist=False,
        backref='parent')

class Child(Base):
    __tablename__ = 'child'
    id = sa.Column(sa.Integer, primary_key=True)
    parent_id = sa.Column(sa.Integer, sa.ForeignKey('parent.id'))

Many-to-Many Relationship

同样，先看使用 ForeignKey 的版本：

association_table = sa.Table('association', Base.metadata,
    sa.Column('left_id', sa.Integer, sa.ForeignKey('left.id')),
    sa.Column('right_id', sa.Integer, sa.ForeignKey('right.id'))
)

class Parent(Base):
    __tablename__ = 'left'
    id = sa.Column(sa.Integer, primary_key=True)
    children = orm.relationship(
        "Child",
        secondary=association_table,
        backref='parents')

class Child(Base):
    __tablename__ = 'right'
    id = Column(Integer, primary_key=True)

不用 ForeignKey 的版本:

association_table = sa.Table('association', Base.metadata,
    sa.Column('left_id', sa.Integer, sa.ForeignKey('left.id')),
    sa.Column('right_id', sa.Integer, sa.ForeignKey('right.id'))
)

class Parent(Base):
    __tablename__ = 'left'
    id = sa.Column(sa.Integer, primary_key=True)
    children = orm.relationship(
        "Child",
        secondary=association_table,
        primaryjoin='left.id == association.left_id',
        secondaryjoin='right.id == association.right_id',
        backref='parents')

class Child(Base):
    __tablename__ = 'right'
    id = Column(Integer, primary_key=True)

Single Table Inheritance

单表继承不需要用到外键，所以可以直接使用：

class Person(Base):
    __tablename__ = 'people'
    id = sa.Column(sa.Integer, primary_key=True)
    discriminator = sa.Column('type', sa.String(50))
    __mapper_args__ = {'polymorphic_on': discriminator}

class Engineer(Person):
    __mapper_args__ = {'polymorphic_identity': 'engineer'}
    primary_language = sa.Column(sa.String(50))

Joined Table Inheritance

外键版本如下：

class Person(Base):
    __tablename__ = 'people'
    id = sa.Column(sa.Integer, primary_key=True)
    discriminator = sa.Column('type', sa.String(50))
    __mapper_args__ = {'polymorphic_on': discriminator}

class Engineer(Person):
    __tablename__ = 'engineers'
    __mapper_args__ = {'polymorphic_identity': 'engineer'}
    id = sa.Column(Integer, sa.ForeignKey('people.id'), primary_key=True)
    primary_language = sa.Column(sa.String(50))

去外键版本如下：

class Person(Base):
    __tablename__ = 'people'
    id = sa.Column(sa.Integer, primary_key=True)
    discriminator = sa.Column('type', sa.String(50))
    __mapper_args__ = {'polymorphic_on': discriminator}

class Engineer(Person):
    __tablename__ = 'engineers'

    _id = sa.Column(Integer, primary_key=True)
    __mapper_args__ = {
        'polymorphic_identity': 'engineer',
        'inherit_condition': (_id == Person.id),
        'inherit_foreign_keys': _id,
    }
    id = orm.column_property(_id, Person.id)
    del _id

    primary_language = sa.Column(sa.String(50))

这里有两个重点，分别是如何表达继承关联，以及如何将两个表的 id 列映射到一个字段上。

在 __mapper_args__ 中我们手动指定了 inherit_condition 和 inherit_foreign_keys 这两个参数来表达和父表的关系。

用 orm.column_property 可以将多个 column 映射到同一个字段上，这里将子表的 id 和父表的 id 都映射到了 id 这个字段上了，并在结束时，清理掉了多余的 _id 这个引用。

其实这里为什么需要将两个 id 列映射到用一个字段上我也不是很清楚，这么做只是为了完整的还原使用外键版本的结果。

小结

所以说，为啥不用外键呢？

SSL 客户端验证

2016-09-27T04:00:00+08:00

对于自己的个人网站，安全要求没有那么重要。如果想对网站做一个简单的身份验证，可以有两种方式：

直接在 Nginx 中配置一个简单的 auth_basic 形式的用户名 & 密码；
或者使用本文要说的 SSL Client Side Authentication；

注：由于 Client Side Authentication 太长，下文会用 CSA 这个缩写来代替。

为什么用这个

两个原因：

安全。这个不用说了，只有拥有证书的人才能被认证，就排除了密码被破解的可能性；
方便。不用输入用户名密码什么的了啊；

配置过程

首先需要明确，CSA 的配置过程和网站的 Server Side Authentication 是完全独立的，两者没有什么关系。

环境准备

安装 openssl 工具。

brew install openssl

准备一个空目录。

mkdir certs
cd certs

创建根证书

# generate primary key
openssl genrsa -des3 -out ca.key 4096
# or if you don't want a password:
openssl genrsa -out ca.key 4096
# generate a cert
openssl req -new -x509 -days 365 -key ca.key -out ca.crt

生成 ca.crt 文件的时候会需要填写一些信息，看着填就好了，关系不大。我是这么填写的：

$ openssl req -new -x509 -days 365 -key ca.key -out ca.crt
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
------
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:Beijing
Locality Name (eg, city) []:Beijing
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:Hongbo He
Common Name (e.g. server FQDN or YOUR name) []:Hongbo He
Email Address []:me@graycarl.me

然后生成的证书长这样：

这里创建的 ca.crt 是会放到服务端的，接下来我们创建安装在客户端的证书。

创建客户端证书

首先是创建证书请求：

openssl genrsa -out client.key 4096
openssl req -new -key client.key -out client.csr

这里同样会需要输入一些信息，看着输入就好。

然后使用 ca 证书进行签发：

openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt

这样就签发好了客户端证书 client.crt。

安装客户端证书

上一步产生的 client.crt 并不能直接安装，需要转成 PKCS 格式：

openssl pkcs12 -export -clcerts -in client.crt -inkey client.key -out client.p12

这里的 client.p12 在 MacOS 上就可以直接双击安装到系统的 KeyChain 里面。

部署到服务器

服务端只需要一个 ca.crt 文件即可。

scp sa.crt somebody@someserver:/etc/nginx/certs/client-auth-ca.crt

Nginx 中加入如下的配置：

server {
    ...
    ssl_client_certificate /etc/nginx/certs/client-auth-ca.crt;
    ssl_verify_client optional;
    ...
}

其中 ssl_verify_client 的值可以是 optional | on 者两个：

当选择 on 时会强制进行客户端认证，失败无法访问；
当选择 optional 的时候，认证是可选的，是否认证成功可以从 $ssl_client_verify 变量得知。

比如，我们想要网站根目录是任意访问的，但是 /admin 路径下是需要认证才能访问的，就可以这么配置：

server {
    ...
    ssl_client_certificate /etc/nginx/certs/client-auth-ca.crt;
    ssl_verify_client optional;
    ...

    location /admin {
        if ($ssl_client_verify != SUCCESS) {
            return 401;
        }
        proxy_pass http://localhost:5000;
    }
}

完成

当打开网站且本机装有对应的客户端证书时，就会出现请求证书认证的提示框：

点确定就可以通过认证啦。

参考

ClientSide SSL

Nginx SSL Module

Alembic 添加不能为空的列

2014-08-14T18:01:00+08:00

当我们对一个已存在数据的Table中添加一个nullable=False的列时，通常alembic会直接报错，因为它不知道要给这个列赋予什么值，所以会默认给个NULL的值，但是这个值与nullable=False的规则冲突了。

通常这种不能为空的列都是应该有一个默认值的，所以可以直接在alembic中指定这个列的默认值：

:::python
op.add_column('callroom', sa.Column('consulvalid', sa.Integer(), nullable=True, server_default=text("0")))

但也有可能这个默认值只想在Python的orm环境中定义，不想定义到数据库中，比如

:::python
class MyClass(Base):
    name = Column(Unicode(40), default=u'hello')

这种情况下，可以这么修改alembic迁移脚本：

:::python
from sqlalchemy.sql import table, column
op.add_column('callroom', sa.Column('consulvalid', sa.Boolean(), nullable=True))
callroom = table("callroom", column("consulvalid", sa.Boolean()))
op.execute(callroom.update().values(consulvalid=False))
op.alter_column("callroom", "consulvalid", nullable=False)

即先增加了一个nullable=True的列，然后将这个列设置默认值后，再改成nullable=False。

SqlAlchemy 标记字段变更

2014-06-16T19:59:00+08:00

为了在数据库里面存储一些比较随意的结构化数据，我参照(抄袭)sqlalchemy的文档实现了一个自定义类型：

class JSON(TypeDecorator):
    """ Json String Field """
    impl = Text

    def process_bind_param(self, value, dialect):
        if value is None:
            return value
        elif isinstance(value, (dict, list)):
            return json.dumps(value)
        else:
            raise ValueError("unsupported value type")

    def process_result_value(self, value, dialect):
        if value is None:
            return value
        else:
            return json.loads(value)


class MyModel(Base):
    ...
    json = Column(JSON, default=[])

    def add_item(self, item):
        self.json.append(item)

其实这本质上就是把python的dict或list直接dumps成json内容存入数据库，从数据库读出之后再自动loads成dict或者list来使用。

但是再使用的过程中发现了一个问题。对这个MyModel的实例无论怎么修改其json字段都无法正常保存到数据库中，目测应该是SA没有检测到这个字段的变化而导致的。重新翻看文档，发现文档里面已经有说明了。

Note that the ORM by default will not detect “mutability” on such a type - meaning, in-place changes to values will not be detected and will not be flushed. Without further steps, you instead would need to replace the existing value with a new one on each parent object to detect changes. Note that there’s nothing wrong with this, as many applications may not require that the values are ever mutated once created. For those which do have this requirement, support for mutability is best applied using the sqlalchemy.ext.mutable extension - see the example in Mutation Tracking.

再看看sqlalchemy.ext.mutable模块的文档，发现使用起来也没有那么简练，而我只想找个方法来主动标记字段变更就行了。于是翻看mutable模块的代码，找到了其最重要的一句：

from sqlalchemy.orm.attributes import flag_modified

class Mutable(MutableBase):

    def changed(self):
        """Subclasses should call this method whenever change events occur."""

        for parent, key in self._parents.items():
            flag_modified(parent, key)

其实就是这个flag_modified标记了修改状态，所以只需要把我自己的代码改一句就行了。

from sqlalchemy.orm.attributes import flag_modified

class MyModel(Base):
    ...
    json = Column(JSON, default=[])

    def add_item(self, item):
        self.json.append(item)
        flag_modified(self, "json")

打完收工。

知识在于积累？知识在于经历

2014-06-06T15:02:00+08:00

今天折腾代码的时候突然有了感悟，也可以说是自己给自己找到的合理的安慰。

我的工作就是在实现各种各样的功能，解决各种各样的问题，所以在这个过程中查阅了无数的资料，用到了无数的技术。

然后，有一天，在寻找一个问题的解决方案的时候，我发现这个问题我以前经历过的，但是现在忘了。于是，只能重新重新在网络上查阅资料。

每当遇到这样的情况的时候我都会很郁闷，感觉这本来是自己已经积累的知识就这么“挥发”了，只能重新积累，等待什么时候再次“挥发”了。

现在这种情况遇到的越来越频繁，让我觉得自己在各种“重复过程“中浪费时间。但我知道事情并不是这样的，只是缺少对这种现象的一种”正确“的看待方式。

于是，标题的文字就这么出来了。

真正的知识并不是对一种技术的熟悉，并不是对某种方案的实现细节的记忆，正真的知识应该是”对这个世界的理解“。当我们对这个世界真正理解之后，所有的”方案“和”技术“等玩意在需要的时候就会不自觉的出现了。

为什么说是”不自觉“的出现呢，因为它可能是在我花了不到一分钟的时间的”Google“后出现，可能是在我花了一分钟时间了解了某个技术的大体框架之后立刻就”猜“出了它的详细用法，甚至是花了一分钟时间思考之后就设计出了”完美“的方案。

而这种知识就是在我为之苦恼的”重复过程“中经历而来的。

所以，你的一切努力都没有白费。

SQLAlchemy 中的级联删除

2014-03-24T16:13:00+08:00

又被一个问题折腾了半天，找到原因，记录下来。

问题描述

使用SQLAlchemy建立一对多的relationship：

class Parent(db.Model):
    __tablename__ = "parent"
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.Text)


class Child(db.Model):
    __tablename__ = "child"
    id = db.Column(db.Integer, primary_key=True)

    parent_id = db.Column(db.Integer,
                          db.ForeignKey("parent.id", ondelete="CASCADE"),
                          nullable=False)
    parent = db.relationship("Parent", backref="children")

    name = db.Column(db.Text)

先增加一个parent和其下的两个child，然后删除这个parent

#增加记录
p = Parent(name="P1")
p.children.append(Child(name="C1"))
p.children.append(Child(name="C2"))
db.session.add(p)
db.session.commit()

#删除记录
db.session.delete(p)
db.session.commit()

报错：

BEGIN (implicit)
SELECT parent.id AS parent_id, parent.name AS parent_name
FROM parent
WHERE parent.id = ?
(1,)
SELECT child.id AS child_id, child.parent_id AS child_parent_id, child.name AS child_name
FROM child
WHERE ? = child.parent_id
(1,)
UPDATE child SET parent_id=? WHERE child.id = ?
(None, 1)
ROLLBACK
Traceback (most recent call last):
  File "main.py", line 44, in <module>
    test()
  File "main.py", line 41, in test
    db.session.commit()
  ……
  File "build/bdist.macosx-10.4-x86_64/egg/sqlalchemy/engine/default.py", line 388, in do_execute
sqlalchemy.exc.IntegrityError: (IntegrityError) child.parent_id may not be NULL u'UPDATE child SET parent_id=? WHERE child.id = ?' (None, 1)

很明显错误原因是由于sa在处理删除parent的时候产生了

'UPDATE child SET parent_id=? WHERE child.id = ?' (None, 1)

这样的SQL语句。而child的外键设置里面明确有nullable=False，所以提交失败。

问题解决

我之前一直以为当我在外键设置里面有ondelete="CASCADE"这一条之后，sa应该会自动产生级联的删除命令，或者只产生单独对parent的删除SQL，让数据库自己产生对child的删除。可事实是sa产生了SET NULL这样的SQL，为什么呢。

网上搜索未果，再从官方文档找答案，终于找到了。

ForeignKey(..ondelete)

这里的ondelete控制的只是创建数据库Schema时候的ONDELETE规则，不会影响运行中sa如何产生SQL命令。

relationship(…cascade)

这里参数参数才会影响sa如何级联产生SQL语句，默认值为save-update, merge，这就是罪魁祸首。

把它设置成all, delete-orphan之后，sa就会产生级联的删除命令，而不是set null命令了。

parent = db.relationship("Parent", backref=db.backref("children",  cascade="all, delete-orphan"))

输出：

BEGIN (implicit)
SELECT parent.id AS parent_id, parent.name AS parent_name
FROM parent
WHERE parent.id = ?
(1,)
SELECT child.id AS child_id, child.parent_id AS child_parent_id, child.name AS child_name
FROM child
WHERE ? = child.parent_id
(1,)
DELETE FROM child WHERE child.id = ?
((1,), (2,))
DELETE FROM parent WHERE parent.id = ?
(1,)
COMMIT

cascade还有很多其他选项，可具体查看文档。

relationship(…passive_deletes)

这是另一种可选的解决方案。

如果想完全靠数据库的ONDELETE规则在自动删除数据，应该将该passive_deletes置为True，这样就不会在删除的时候产生多余的SQL命令了。

parent = db.relationship("Parent", backref=db.backref("children",  passive_deletes=True))

输出:

SELECT parent.id AS parent_id, parent.name AS parent_name
FROM parent
WHERE parent.id = ?
(1,)
DELETE FROM parent WHERE parent.id = ?
(1,)
COMMIT

Python datetime and timezone

2014-03-21T15:17:00+08:00

悲剧的发现之前一直都理解有误啊，仔细读了一遍文档，这里做个记录。

基本类型

datetime库里面主要有这么五种数据：

date
datetime
time
timedelta
tzinfo

date

date表示纯粹的日期数据，即“2020-02-21”这种，不含时区概念。

文档里面有这么一句：

January 1 of year 1 is called day number 1, January 2 of year 1 is called day number 2, and so on.

在加上date.fromordinal和date.toorinal这两个方法，我觉得其内部可能就是用day number这个整型数来表示的。不过这个无所谓啦。

time

time表示时间数据，即”12:22:34”这种，但是它是可以有时区概念time.tzinfo在里面的。

关于Time Zone的东西下面会详细说，这里先不说了。

datetime

datetime是date和time的结合体，表示完整的时间概念，即”2014-02-21 12:23:23”这种。也是可以有时区概念的。

另外，datetime是date的子类。

timedelta

timedelta表示时间长度（时间差），很好理解，没啥好说的。

tzinfo

即Time Zone Info，时区信息。这个原始的tzinfo是一个抽象基类，不应该直接实例化，应该子类化并实现一些必要函数再使用。

需要实现的函数如下：

tzinfo.utcoffset(self, dt)
tzinfo.dst(self, dt)
tzinfo.tzname(self, dt)

待实现的这些函数主要都是用于被datetime或者time实例调用。逻辑会在下面说明。

关于时区

上面说到datetime和time是可以有时区概念的，为什么是可以有呢？

先从文档里面直接拿出两个名词：

There are two kinds of date and time objects: “naive” and “aware”.

“Naive” Object表示单纯的时间数据，不包含时区信息，所以无法直接进行时区转换等操作。

“Aware” Object表示包含了时区信息的时间数据，这其实才是真实世界中可以在时间轴上找到自己位置的对象。由于带有了时区信息，所以也就原生支持了各时区转换等操作。

同样是一个datetime(或者time)对象，当datetime.tzinfo is None时它就是”naive”的，否则datetime.tzinfo存放了时区信息，它就是”aware”的。

让一个naive对象变成aware对象最直接的方法就是给它设置一个tzinfo对象：

n = datetime.now()
# 注意，replace方法只会直接修改属性值，不会自动根据时区做时间调整
n.replace(tzinfo=sometz)

如果对一个naive对象调用一些跟时区相关的方法(如: datetime.astimezone)，就会报错或无效，因为这些方案的实现中通常需要使用datetime.tzinfo中实现的方法。

tzinfo只是一个抽象基类，定义了一些子类化时候需要实现的方案，在python的标准库里面没有任何实现。

可以为什么呢？标准库里面不应该有一些基本的通用的实现么。猜测估计是由于当前世界上各时区的混乱（还有夏令时这种奇葩的东西），以及各平台下时区信息的存储方式的差异，导致不适合在标准库里面实现吧。

实现一个最简单的UTC Time Zone如下：

from datetime import tzinfo, timedelta

ZERO = timedelta(0)

class UTC(tzinfo):
    # 本时区与UTC时间的差值
    def utcoffset(self, dt):
        return ZERO

    # 时区名称
    def tzname(self, dt):
        return “UTC”

    # 夏令时
    def dst(self, dt):
        return ZERO

当然也没有必要真的就自己手动实现，使用pytz或者dateutils这些第三方库就好了。

关于时间戳(TimeStamp)

时间戳的含义就是UTC时间1970-01-01 00:00:00到当前时间的秒数，这本质上是一个时间差，所以没有时区的概念。

对于时间戳的操作，主要涉及的是另一个标准库time，注意这里的time并不是datetime.time。

获取当前时间戳:

import time
current_timestamp = time.time()

使用Naive对象

标准库里面没有实现tzinfo，所以如果我们没有使用第三方库，那么我们一定都是在使用Naive对象了。

但是，实际情况是即时我们使用的都是Naive对象，还是会有Local时间和UTC时间的区分！这就是我之前一直很混乱的地方。

其实，如果只需要做本地时间和UTC时间的转换是用不着tzinfo的。

datetime.now([tzinfo])

datetime.now是一个类函数，返回表示当前时间的datetime对象。它有一个可选参数，可传入一个具体的时区信息来返回指定时区的当前时间。如果不带参数调用，那么它会返回本地时间的naive对象。

比如，我现在是北京时间2014-03-21 14:11:00:

>>> from datetime import datetime
>>> now = datetime.now()
>>> print now
2014-03-21 14:11:23.414917

虽然返回的是本地时间（北京时间），但是它是naive对象，不带时区信息！

>>> print now.tzinfo
None

如果想要得到UTC时间:

>>> utcnow = datetime.utcnow()
>>> print utcnow
2014-03-21 06:16:10.025043

datetime <=> timestamp

本地时间和时间戳之间转换:

>>> now = datetime.now()
>>> print now
2014-03-21 14:22:11
>>> ts = time.mktime(now.timetuple())
>>> print ts
1395382931.0
>>> _now = datetime.fromtimestamp(ts)
>>> print _now
2014-03-21 14:22:11

如果想把时间戳转成UTC时间:

>>> _utcnow = datetime.utcfromtimestamp(ts)
>>> print _utcnow
2014-03-21 06:22:11

如果想把UTC时间转成时间戳:

>>> ts = time.mktimefromutc(datetime.utcnow().timetuple())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'mktimefromutc'

好吧，总觉得time里面缺少这这么个函数，不过我们可以这么来：

utcnow = datetime.utcnow()
ts_from_utcdt = time.mktime(utcnow.timetuple()) - time.timezone

或者:

import calendar
ts_from_utcdt = calendar.timegm(utcnow.timetuple())

又用到了calendar这个库，真够乱的。

Local DateTime <=> UTC DateTime

对于naive对象，貌似没有方法能够直接支持本地时间和UTC时间转换的，所以只能从TimeStamp中绕一圈了。

Local DateTime => UTC DateTime

>>> print now
2014-03-21 14:41:42.529159
>>> ts = time.mktime(now.timetuple())
>>> utcnow = datetime.utcfromtimestamp(ts)
>>> print utcnow
2014-03-21 06:41:42

UTC DateTime => Local DateTime

>>> utc = datetime.utcnow()
>>> print utc
2014-03-21 06:44:15.069810
>>> ts = time.mktime(utc.timetuple()) - time.timezone
>>> local = datetime.fromtimestamp(ts)
>>> print local
2014-03-21 14:44:15

使用Aware对象

如果使用Aware对象，一些貌似都清晰了不少。

datetime.now([tzinfo])

我们可以返回一个指定时区的datetime

>>> from datetime import datetime
>>> import pytz
>>> tz_cn = pytz.timezone("Asia/Shanghai")
>>> tz_us = pytz.timezone('America/Los_Angeles')
>>> print datetime.now(tz_cn)
2014-03-21 14:58:38.059945+08:00
>>> print datetime.now(tz_us)
2014-03-20 23:58:45.427634-07:00
>>> print datetime.now(pytz.UTC)
2014-03-21 06:58:56.507517+00:00

并且它是aware的

>>> dt_cn = datetime.now(tz_cn)
>>> dt_cn.tzinfo
<DstTzInfo 'Asia/Shanghai' CST+8:00:00 STD>

时区转换

对于aware对象之间的转换很简单:

>>> dt_cn = datetime.now(tz_cn)
>>> print dt_cn
2014-03-21 15:04:21.700744+08:00
>>> dt_us = dt_cn.astimezone(tz_us)
>>> print dt_us
2014-03-21 00:04:21.700744-07:00

对于非aware的对象，可以先将其转换成aware的再操作：

>>> dt_naive = datetime.utcnow()
>>> print dt_naive
2014-03-21 07:05:58.194690
>>> dt_utc = dt_naive.replace(tzinfo=pytz.UTC)
>>> print dt_utc
2014-03-21 07:05:58.194690+00:00
>>> dt_cn = dt_utc.astimezone(tz_cn)
>>> print dt_cn
2014-03-21 15:05:58.194690+08:00

对于aware对象和时间戳的转换，我觉得还是全都转成UTC时间再操作吧。

纠结的Many-Many关联

2014-01-23T21:00:00+08:00

使用了SQLAlchemy挺长时间的了，之前在使用的过程中一直有一件事挺纠结的，SA到底会不会在commit的使用自动对比多对多关系的变更生成合适的SQL去更新数据库呢？

现决定做具体实验，搞清楚。

数据定义

数据定义如下:

:::python
class Right(Base):
    """ 权限表 """
    __tablename__ = "right"
    name = Column(String(16), primary_key=True)

    def __repr__(self):
        return "<Right(name=%s)>" % self.name


user_right = Table(
    "user_right", Base.metadata,
    Column("user_id", Integer, ForeignKey("user.id", ondelete="CASCADE")),
    Column("right", String(16), ForeignKey("right.name", ondelete="CASCADE"))
)


class User(Base):
    __tablename__ = "user"

    id = Column(Integer, primary_key=True)
    name = Column(String(100), unique=True)
    age = Column(Integer, nullable=False)
    rights = relationship(Right, secondary=user_right)

    def __repr__(self):
        return "<User(name=%s)>" % self.name

添加关联

当得到了user实例后，如果新增一个关联的right:

:::python
user.rights.append(newright)
session.commit()

正常识别出了新增的关联并且生成了合适的SQL。

减少关联

如果减少一个关联:

:::python
user.rights.remove(someright)
session.commit()

正常识别出了新增的关联并且生成了合适的SQL。

重置关联

这种方式是最值得怀疑的，不再是修改关联，而是重置关联：

:::python
user.rights = [someright1, someright2]
session.commit()

结果是，一切正常运行。看来SA的确做的很到位了。

结论

以后可以不用纠结，直接把对比更新的复杂度丢给SA去处理就好了。

关于Gitignore的规则

2014-01-22T11:00:00+08:00

关于.gitignore的语法规则我一直没有很明白，今天决心要弄懂。

下面的是Manual Page的说明：

A blank line matches no files, so it can serve as a separator for readability.

A line starting with # serves as a comment. Put a backslash (“") in front of the first hash for patterns that begin with a hash.

An optional prefix “!” which negates the pattern; any matching file excluded by a previous pattern will become included again. If a negated pattern matches, this will override lower precedence patterns sources. Put a backslash (“") in front of the first “!” for patterns that begin with a literal “!”, for example, “!important!.txt”.

If the pattern ends with a slash, it is removed for the purpose of the following description, but it would only find a match with a directory. In other words, foo/ will match a directory foo and paths underneath it, but will not match a regular file or a symbolic link foo (this is consistent with the way how pathspec works in general in git).

If the pattern does not contain a slash /, git treats it as a shell glob pattern and checks for a match against the pathname relative to the location of the .gitignore file (relative to the toplevel of the work tree if not from a .gitignore file).

Otherwise, git treats the pattern as a shell glob suitable for consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the pattern will not match a / in the pathname. For example, “Documentation/*.html” matches “Documentation/git.html” but not “Documentation/ppc/ppc.html” or “tools/perf/Documentation/perf.html”.

A leading slash matches the beginning of the pathname. For example, “/*.c” matches “cat-file.c” but not “mozilla-sha1/sha1.c”.

我仔细读了半天，发现还是没弄懂，还是亲自做实验吧。

其实没弄懂的主要是第4，5，6条，一个个解决吧。

If the pattern ends with a slash

原文这样：

If the pattern ends with a slash, it is removed for the purpose of the following description, but it would only find a match with a directory. In other words, foo/ will match a directory foo and paths underneath it, but will not match a regular file or a symbolic link foo (this is consistent with the way how pathspec works in general in git).

正常情况:

Carl-MBPR ➜  testgitignore git:(master) ✗ cat .gitignore
foo/
Carl-MBPR ➜  testgitignore git:(master) ✗ tree -a -L 1
.
├── .git
├── .gitignore
└── foo
Carl-MBPR ➜  testgitignore git:(master) ✗ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   foo
nothing added to commit but untracked files present (use "git add" to track)
Carl-MBPR ➜  testgitignore git:(master) ✗ rm foo
Carl-MBPR ➜  testgitignore git:(master) mkdir foo
Carl-MBPR ➜  testgitignore git:(master) touch foo/file
Carl-MBPR ➜  testgitignore git:(master) tree -L 2
.
└── foo
    └── file

1 directory, 1 file
Carl-MBPR ➜  testgitignore git:(master) git status
# On branch master
nothing to commit, working directory clean

子目录中的表现：

Carl-MBPR ➜  testgitignore git:(master) mkdir somefolder
Carl-MBPR ➜  testgitignore git:(master) touch somefolder/foo
Carl-MBPR ➜  testgitignore git:(master) ✗ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   somefolder/
nothing added to commit but untracked files present (use "git add" to track)
Carl-MBPR ➜  testgitignore git:(master) ✗ rm somefolder/foo
Carl-MBPR ➜  testgitignore git:(master) mkdir somefolder/foo
Carl-MBPR ➜  testgitignore git:(master) touch somefolder/foo/file
Carl-MBPR ➜  testgitignore git:(master) git status
# On branch master
nothing to commit, working directory clean

结论：这里的规则是在所有目录层级中都有效的。

If the pattern does not contain a slash

If the pattern does not contain a slash /, git treats it as a shell glob pattern and checks for a match against the pathname relative to the location of the .gitignore file (relative to the toplevel of the work tree if not from a .gitignore file).

实验：

Carl-MBPR ➜  testgitignore git:(master) cat .gitignore
foo

正常情况：

Carl-MBPR ➜  testgitignore git:(master) touch foo
Carl-MBPR ➜  testgitignore git:(master) git status
# On branch master
nothing to commit, working directory clean

Carl-MBPR ➜  testgitignore git:(master) rm foo
Carl-MBPR ➜  testgitignore git:(master) mkdir foo
Carl-MBPR ➜  testgitignore git:(master) touch foo/file
Carl-MBPR ➜  testgitignore git:(master) tree
.
└── foo
    └── file

1 directory, 1 file
Carl-MBPR ➜  testgitignore git:(master) git status
# On branch master
nothing to commit, working directory clean

子目录中表现：

Carl-MBPR ➜  testgitignore git:(master) mkdir somefolder
Carl-MBPR ➜  testgitignore git:(master) touch somefolder/foo
Carl-MBPR ➜  testgitignore git:(master) tree
.
├── foo
│   └── file
└── somefolder
    └── foo

2 directories, 2 files
Carl-MBPR ➜  testgitignore git:(master) git status
# On branch master
nothing to commit, working directory clean

结论：这里的规则也是对所有子目录有效。

Otherwise, git treats the pattern as a shell glob suitable for consumption by fnmatch(3) with the FNM_PATHNAME flag

原文:

Otherwise, git treats the pattern as a shell glob suitable for consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the pattern will not match a / in the pathname. For example, “Documentation/*.html” matches “Documentation/git.html” but not “Documentation/ppc/ppc.html” or “tools/perf/Documentation/perf.html”.

实验：

Carl-MBPR ➜  testgitignore git:(master) cat .gitignore
foo/*.file

正常情况：

Carl-MBPR ➜  testgitignore git:(master) mkdir foo
Carl-MBPR ➜  testgitignore git:(master) touch foo/aa
Carl-MBPR ➜  testgitignore git:(master) ✗ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   foo/
nothing added to commit but untracked files present (use "git add" to track)
Carl-MBPR ➜  testgitignore git:(master) ✗ mv foo/aa foo/aa.file
Carl-MBPR ➜  testgitignore git:(master) tree
.
└── foo
    └── aa.file

1 directory, 1 file
Carl-MBPR ➜  testgitignore git:(master) git status
# On branch master
nothing to commit, working directory clean

子目录中表现：

Carl-MBPR ➜  testgitignore git:(master) mkdir somefolder
Carl-MBPR ➜  testgitignore git:(master) mkdir somefolder/foo
Carl-MBPR ➜  testgitignore git:(master) touch somefolder/foo/some.file
Carl-MBPR ➜  testgitignore git:(master) ✗ tree
.
├── foo
│   └── aa.file
└── somefolder
    └── foo
        └── some.file

3 directories, 2 files
Carl-MBPR ➜  testgitignore git:(master) ✗ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   somefolder/
nothing added to commit but untracked files present (use "git add" to track)

结论：该类型规则不会在子目录中生效。

总结

当规则是简单文件（目录）名的匹配的话，会在当前目录和子目录中生效。
如果规则中包含的路径（即使不是绝对路径），该规则都只会在当前目录生效。
可以使用/foo的形式来从项目根目录开始匹配。