自動化平臺開發小結（四）

今天對備份恢復和後設資料的功能點進行了改進，突然發現需要做的事情遠比想象的要多。

技術方面，目前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來做一些深度的定製，而不完全依賴外來鍵關係。

明天繼續大搞一場，把剩下的功能搞定。