提到Python的ORM，首先想到的有两个SQLObject和SqlAlchemy，还有Django的ORM，另外，还有Zope的。 前几日和Nicholas又讨论到SQLObject这个东西，就目前Python现有的ORM工具来说，最容易使用还是它了，SqlAlchemy对于懒人、初学者的我来说，还是复杂了点；而Zope相对是个庞然大物，整体的解决方案，小东西往往也不会去用到。 当然SQLObject的问题不在于它使用了ActiveRecord模式，Django的ORM同样也用到了这个模式，因为起初用TurboGears（0.8.9，当时SO的版本可能还没到0.7）做了一个小东西，那个时候便发现了诸多问题，尤其在编码问题上卡住了。这一次正准备对原有的东西增加新的功能，便几乎无法做下去了。 比如业务领域有“角色”这个词，在业务上应当翻译成“Character”。我建立了一个Character类，SO在自动根据代码的Model建立表结构的时候，不会像Rails那样考虑单复数，因此它会尝试建立“character”表，而Character、Char在mysql中都是保留词，而SQLObject甚至都不知道在SQL语句中对其进行转义。为了解决这个问题，我指定SO去建立characters表，接下来的问题就是，SO在寻找Character表相关的外键时，是考虑了characters_id，而对于存在这个外键的表，SO在建表的时候还是使用了character_id这个名字，最终导致了错误。 另外编码又有新问题，Python中使用%格式化操作符时，左边或右边任意一方出现了unicode字符串，最后的结果都会是unicode，而SO也同样没有考虑到，最后导致本已经是unicode的查询字符串，SO还要去再decode一次，最后导致了错误。 所以不推荐大家使用SO，尤其要做复杂产品的时候。 另外，Django的ORM也可以拿出来单独使用，值得研究一下。
Tag Archives: ORM
PEAR DB_Table 简介
翻译：ShiningRay @ NirvanaStudio 原文地址：http://wiki.ciaweb.net/yawiki/index.php?area=DB_Table 什么是 DB_Table? DB_Table 是一个用于访问数据库表的面向对象接口。作为一个PEAR DB类的一个 包装，它提供了一些帮助你构建自动的创建、插入、更新和选择功能的方法。同时还有利用 HTML_QuickForm 自动构建输入表单的方法。 DB_Table提供了什么？ DB_Table 提供了： 一个嵌在类属性中的模式描述系统，包括： 列定义 索引定义 标准查询 创建HTML_QuickForm元素的属性 从描述的模式自动创建表 一个抽象的API这样即便你改变了数据库后台也不需要改变你的PHP调用。这套API扩展了PEAR DB的功能，同时包含： 用于根据预定义的SQL查询来获取一个结果数组的select() 方法 用于根据预定义的SQL查询来获取一个PEAR DB_Result 对象的selectResult() 方法 create(), insert(), update(), 和 delete() 方法 自动模式检验 根据描述的表模式进行插入和更新字段时的自动检验 时间和日期数据类型抽象，覆盖了数据库的原始数据类型 … 即使你更改了数据库的后端，也无需修改你的查询。 不需要通过类型转换方法来改变查询的值。 当你插入或者更新列时，DB_Table 根据DB_Table 数据类型自动检验数据（datatype automatically (对所有的数据类型: integer, string,等等.). 根据描述的模式自动创建HTML_QuickForm元素，利用以下方法： getForm() 获取整个表单对象，有HTML_QuickForm元素和规则。 getFormGroup() 获取一组HTML_QuickForm元素。 getFormElement() 获取单一的HTML_QuickForm元素 [...]
