今天對備份恢複和中繼資料的功能點進行了改進，突然發現需要做的事情遠比想象的要多。
技術方面，目前Django的架構使用開始有一些需求的瓶頸了，因為有些需求從業務的角度來說，能夠實作是極好的，但是從Django的支援層面來說，有些需求要實作就比較糾結了，比如預設的User，如果想在已有的基礎上擴充，技術肯定能夠實作，但是就有不少需要注意的細節，折騰一圈，基本會是這樣的一個态度。
而且尤其讓我有些不得力的是ORM的API,對于增删改查來說是足夠了，但是我要實作一些相對複雜的統計需求的時候，這種方式就很受限了，使用raw的方式吧，有些SQL可能會寫的比較長，而且查詢結果很可能不需要主鍵，會報出下面的錯誤：InvalidQuery: Raw query must include the primary key
是以在這個地方又開始糾結了，甚至于想到底還有沒有其他更好的ORM實作，
顯然是有的，比如SQL Alchemy,還有很多公司是自己定制的ORM.
但是話說回來，Django本身很全面，強大的社群支援是很顯然的。但是退一步來看，我們是否有更好或者Django也提供了一些定制的入口。
Django的流行可以參考這篇。
是以糾結貴糾結，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來做一些深度的定制，而不完全依賴外鍵關系。
明天繼續大搞一場，把剩下的功能搞定。