LeanCloud SDK不好用，Python手写一个ORM

Intro

惯例，感觉写了好用的东西就来写个博客吹吹牛逼。

LeanCloud Storage 的数据模型不像是一般的 RDBMS，但有时候又很刻意地贴近那种感觉，所以用起来就很麻烦。

LeanCloud SDK 的缺陷

不管别人认不认可，这些问题在使用中我是体会到不爽了。

数据模型声明

LeanCloud 提供的 Python SDK ，根据文档描述来看，只有两种简单的模型声明方式。

1import leancloud
2
3# 方式1
4Todo = leancloud.Object.extend("Todo")
5# 方式2
6class Todo(leancloud.Object): pass

你说字段？字段随便加啊，根本不检查。看看例子。

1todo = Todo()
2todo.set('Helo', 'world') # oops. typo.

忽然就多了一个新字段，叫做Helo。当然，LeanCloud 提供了后台设置，允许设置为不自动添加字段，但是这样有时候你确实想更新字段时——行，开后台，输入账号密码，用那个渲染40行元素就开始轻微卡顿的数据页面吧。

鬼畜的查询Api

是有点标题党了，但讲道理的说，我不觉得这个Api设计有多优雅。

来看个查询例子，如果我们要查找叫做 Product 的，创建于 2018-8-1 至 2018-9-1 ，且 price 大于 10，小于100的元素。

1leancloud.Query(cls_name)\
2	.equal_to('name', 'Product')\
3    .greater_than_or_equal_to('createdAt', datetime(2018,8,1))\
4    .less_than_or_equal_to('createdAt', datetime(2018,9,1))\
5    .greater_than_or_equal_to('price', 10)\
6    .less_than_or_equal_to('price',100)\
7    .find()

第一眼看过去，阅读全文并背诵？

隐藏于文档中的行为

典型的就是那个查询结果是有限的，最高1000个结果，默认100个结果。在Api中完全无法察觉——find嘛，查出来的不是全部结果？你至少给个分页对象吧，说好的代码即文档呢。

幸运的是至少在文档里写了，虽然也就一句话。

行为和预期不符

以一个简单的例子来说，如果你查找一个对象，查找不到怎么办？

返回个空指针，返回个None啊。

LeanCloud SDK 很机智地丢了个异常出来，而且各种不同类型的错误都是这个 LeanCloudError 异常，里面包含了code和error来描述错误信息。

针对于存储个人糊出来的解决方案

我就硬广了，不过这个东西还在施工中，写下来才一天肯定各种不到位，别在意。

better-leancloud-storage-python

简单的说，针对于上面提到的痛点做了一些微小的工作。

微小的工作

直接看例子。

1class MyModel(Model):
2	__lc_cls__ = 'LeanCloudClass'
3	field1 = Field()
4    field2 = Field()
5    field3 = Field('RealFieldName')
6    field4 = Field(nullable=False)
7MyModel.create(field4='123') # 缺少 field4 会抛出 KeyError 异常
8MyModel.query().filter_by(field1="123").filter(MyModel.field1 < 10)

__lc_cls__是一个用于映射到 LeanCloud 实际储存的 Class 名字的字段，当然如果不设置的话，就像 sqlalchemy 一样，类名 MyModel 就会自动成为这个字段的值。

create 接受任意数量关键字参数，但如果关键字参数没有覆盖所有的nullable=False的字段，则会立即抛出KeyError异常。

filter_by接受任意数量关键字参数，如果关键字不存在于Model声明则立即报错。api 和 sqlalchemy 很像，filter_by(field1='123')比起写 equal_to('field1', '123')是不是更清晰一些？特别是条件较多的情况下，优势会越发明显，至少，不至于背课文了。

实现方式分析

装逼之后就是揭露背后没什么技术含量的技巧的时间。

简单易懂的元类魔法

python 的元类很好用，特别是你需要对类本身进行处理的时候。

对于数据模型来说，我们需要收集的东西有当前类的所有字段名，超类（父类）的字段名，然后整合到一起。

做法简单易懂。

收集字段

首先是遍历嘛，遍历找出所有的字段，isinstance就好了。

1class ModelMeta(type):
2    """
3    ModelMeta
4    metaclass of all lean cloud storage models.
5    it fill field property, collect model information and make more function work.
6    """
7    _fields_key = '__fields__'
8    _lc_cls_key = '__lc_cls__'
9
10    @classmethod
11    def merge_parent_fields(mcs, bases):
12        fields = {}
13
14        for bcs in bases:
15            fields.update(deepcopy(getattr(bcs, mcs._fields_key, {})))
16
17        return fields
18    
19    def __new__(mcs, name, bases, attr):
20        # merge super classes fields into __fields__ dictionary.
21        fields = attr.get(mcs._fields_key, {})
22        fields.update(mcs.merge_parent_fields(bases))
23
24        # Insert fields into __fields__ dictionary.
25        # It will replace super classes same named fields.
26        for key, val in attr.items():
27            if isinstance(val, Field):
28                fields[key] = val
29
30        attr[mcs._fields_key] = fields

思路就是一条直线，什么架构、最佳实践都滚一边，用粗大的脑神经和头铁撞过去就是了。

第一步拿出所有基类，找出里面已经创建好的__fields__，然后合并起来。

第二步遍历一下本类的成员（这里可以直接用{... for ... in filter(...)}不过我没想起来），找出所有的字段成员。

第三步？合并起来，一个update就完事儿了，赋值回去，大功告成。

字段名的默认值

还没完事儿，字段名怎么映射到 LeanCloud 存储的字段上？

直接看代码。

1    @classmethod
2    def tag_all_fields(mcs, model, fields):
3        for key, val in fields.items():
4            val._cls_name = model.__lc_cls__
5            val._model = model
6
7            # if field unnamed, set default name as python class declared member name.
8            if val.field_name is None:
9                val._field_name = key
10	
11    def __new__(mcs, name, bases, attr):
12    	# 前略
13		# Tag fields with created model class and its __lc_cls__.
14        created = type.__new__(mcs, name, bases, attr)
15        mcs.tag_all_fields(created, created.__fields__)
16        return created

就在那个tag_all_fields里面，val._field_name赋值完事儿。不要在乎那个field_name和_field_name，一个是包了一层的只读getter，一个是原始值，仅此而已。为了统一也许后面也改掉。

苦力活

有了元数据，接下来的就是苦力活了。

create怎么检查是不是满足所有非空？参数的键和非空的键做个集合，非空键如果不是参数键的子集也不等同则不满足。

filter_by同理。

构建查询也不困难，大家都知道a<b可以重载__lt__来返回个比较器之类的东西。

慢着，怎么让一个实例，用instance.a访问到的内容和model.a访问到的内容不一样？是在init、new方法里做个魔术吗？

实例访问字段值

说穿了也没什么特别的，在实例里面用实际字段值覆盖重名元素很简单，self.field = self.delegated_object.get('field')也就一句话的事情，多少不过是 setattr和getattr的混合使用罢了。

不过我用的是重载 __getattribute__和__setattr__的方法，同样不是什么难理解的东西。

__getattribute__会在所有的实例成员访问之前调用，用这个方法可以拦截掉所有instance.field形式的对field的访问。所以说python是个基于字典的语言一点也不玩笑（开玩笑的）。

看代码。

1    def __getattribute__(self, item):
2        ret = super(Model, self).__getattribute__(item)
3        if isinstance(ret, Field):
4            field_name = self._get_real_field_name(item)
5
6            if field_name is None:
7                raise AttributeError('Internal Error, Field not register correctly.')
8
9            return self._lc_obj.get(field_name)
10
11        return ret

需要特别注意的点是，因为在__getattribute__里访问成员也会调用到自身，所以注意树立明确的调用分界线：在分界线外，所有成员值访问都会造成无限递归爆栈，分界线内则不会。

对于我写的这段来说，分界线是那个 if isinstance(...)。在if之外必须使用super(...).__getattribute__(...)来访问其他成员。

至于 __setattr__更没什么好说的了。看看是不是模型的字段，然后转移一下赋值的目标就是了。