今天对备份恢复和元数据的功能点进行了改进，突然发现需要做的事情远比想象的要多。

技术方面，目前Django的框架使用开始有一些需求的瓶颈了，因为有些需求从业务的角度来说，能够实现是极好的，但是从Django的支持层面来说，有些需求要实现就比较纠结了，比如默认的User，如果想在已有的基础上扩展，技术肯定能够实现，但是就有不少需要注意的细节，折腾一圈，基本会是这样的一个态度。

而且尤其让我有些不得力的是ORM的API,对于增删改查来说是足够了，但是我要实现一些相对复杂的统计需求的时候，这种方式就很受限了，使用raw的方式吧，有些SQL可能会写的比较长，而且查询结果很可能不需要主键，会报出下面的错误：InvalidQuery: Raw query must include the primary key

所以在这个地方又开始纠结了，甚至于想到底还有没有其他更好的ORM实现，

显然是有的，比如SQL Alchemy,还有很多公司是自己定制的ORM.

但是话说回来，Django本身很全面，强大的社区支持是很显然的。但是退一步来看，我们是否有更好或者Django也提供了一些定制的入口。

Django的流行可以参考这篇。

为什么 Django 能持续统治 Python 开发世界

所以纠结贵纠结，Django的这些扩展支持是有的。比如我要实现一个复杂的查询需求。可以使用如下的方式，这个是已有的ORM显然支持不了的。

问题的背景是，有如下的备份文件，大小有的标识是M,有的是G,如果想做数据的统计，基于不同的时间维度，那么要做这件事情就需要做一些过滤了。

| aaa | 9.1G |

| bbb | 11G |

| ccc | 19G |

| ddd | 5.8M |

| eee | 5.7M |

所以我们完全可以使用自定义的方式来做，这个和很多ORM框架类似。

from django.db import connection

cursor = connection.cursor()

cursor.execute(

"SELECT truncate(sum( CASE WHEN RIGHT (backup_size, 1) = 'G' THEN CONCAT( BINARY ( substring( backup_size, 1, LENGTH(backup_size) - 1 ) ) * 1024, 'M' ) ELSE replace(backup_size,'M','') END),0) backup_size FROM test where date_format(backup_starttime,'%y-%m-%d')=date_sub(curdate(),interval 2 day) group by date_format(backup_starttime,'%y-%m-%d');");

total_size = cursor.fetchone()[0]

如此一来，我可以考虑写一个DAO层，复杂的语句和查询都可以通过这个入口来管控，而平常使用的增删改查使用Django API足矣。

如此一来，我一直比较纠结的多对多的一些映射关系和定制也有了新的思路。

可能我就可以直接基于ORM来做一些深度的定制，而不完全依赖外键关系。

明天继续大搞一场，把剩下的功能搞定。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2152351/，如需转载，请注明出处，否则将追究法律责任。