Official Python Planet@Taiwan

在有 Database 的應用裡，寫多了 SQL（Structure Query Language） 會覺得他是一種累贅，讓你的邏輯不斷的，在程式語言，及 SQL 之間轉換，所以後來，就有了，很流行的 Database ORM (Object Relational Mapper) 來幫助我們開發，一來，可以用相同的邏輯思考方式，用物件的方式，去對應資料庫的元件，一來，可以有資料庫的抽象層，對一個系統的開發有很大的助益，但是，如果，要寫的 code ，比一般的 SQL 還要複雜，還要隴長，你該怎麼作呢？

寫回去 SQL 嗎？還是就去適應這樣的物件對應方式？

這也許沒有一定的答案，不過，我來分享一下，我用 Django ORM 到目前所遇到的問題，和解決的方法，所以，裡面有一些是個人好惡的選擇

• 現在Unicode 的branch 還沒有 merge 到 truck 裡，如果用 wxPython unicode 的版本，自己要處理，string to unicode 及 unicode to string 的問題
• ManytoManyField 的欄位，Q object OR 沒有辦法套用，在 djangosnippets 有解決辦法，連結是 http://www.djangosnippets.org/tags/m2m/ 不過還是希望有官方的
• 目前如果是用 truk 的 Django， 用 groupu_by() 只能在對應該物件的 database table 裡分 group，無法使用別的欄位作 group_by 的條件，在別的 branch 有解決了，可是基於，愛乾淨不要混用，太多 branch 的原則，我是用 extra 的解法，算是走 SQL 的回頭路，不過， "GROUP BY" 在 SQL 也是標準的語法，不至於破壞了資料庫的抽象層，不過，如果有用 GROUP BY 的話，不可以混用 filter 的功能，不然，產生的 SQL 語法不對，我們要決定所有的 where 條件，第一個例子，是有 where 的 group by，第二個，是沒有 whehe 可是要強加 grouop by 在不同欄位，這樣就還可以在 DB 上只用一個 query，在 Django 上還是傳回 QuerySet 的作法，不過，這一個 QuerySet 不可以再用 filter 的方式，因為這樣會讓 group by 及 where 的位置錯了

範例1:

qset = Stock.objects.extra(select={'totalsum':'sum(volume)'},where=["customer_id='%s' group by product_id" %(customerid)])

範例2:

qset = Stock.objects.extra(select={'totalsum':'sum(volume)'},where=["1 group by product_id"])

以上，是目前，我遇到的一些限制，及解決辦法，也許對您有參考的價值，在 Desktop 的應用程式上， 如果，還有更複雜的的需求， SQLAlchemy 應該是不錯的選擇

每個人做出選擇都有許多的原因，我來說說我的。

話說去年秋末的時候，手上用 TurboGears 寫的東西，就快完成了，在一個天氣不錯的週末，趕著回家，notebook 掉了，泣，裡面，裝著我三四個月的努力，最後，當然是沒有像電視報導那樣，被善心人士撿到送到警察局，所以證件重辦，電腦重買，系統重寫，要重寫的時候，TurboGears 轉變的非常快，SQLObject 到 SQLAlchemy，範本系統則是 Kid 到 Genshi，而且開發進行的飛快，API 也不確定，所以那時候就選了 Django 來重寫，沒錯，我選的原因是，notebook 掉了，當時沒有時間等 API 穩定了

這一個真實的例子，告訴我們 Version Control 的重要，就算是只有一個人在寫也不例外

最令人高興的事，這兩個專案，都一直有進步

參考資料

http://www.turbogears.org/ TurboGears

http://www.djangoproject.com/ Django

最近作一個公司內部簡單的應用，希望不要讓使用者再去記憶更多密碼，所以 POP3Backend 於是誕生，可以直接用公司的 POP3 Server 來作認證，會先試試 POP SSL 來連，不行才用一般的 POP 連結，真的是很短啦，有一點陽春，用了一個需外裝的 python dns 模組，來查網域的 MX 資料，還有很大的改善空間，不過還是可用啦，一樣，版權沒有，自己取用，責任自負

雖然也很想用 LDAP，不過，內部系統雜亂的歷史包袱，還一時改變不了，還是先撐一下吧，說到認證，不免要抱怨一下，什麼時候，台灣才有正式的非商業，OpenID service provider 壓

連結在這 http://www.djangosnippets.org/snippets/203/

參考資料

http://www.carthage.edu/webdev/?p=12 ，LDAP Authentication in Django with Backends http://www.djangoproject.com/documentation/authentication/ ，User authentication in Django

果然，自己又當了一次小白，我錯怪了 Django

原來是自己修改了 mysql backend 的 base.py 才會造成怪怪的編碼問題，精神不好的時候，還是，看看資料，想想計畫，不要寫太多東西

最近在做的東西，是用 MySQL （懶，已經有 MySQL了，不想再裝 PostgreSQL 了），在資料庫上預設用 UTF8 編碼，在 Django 上，如果 DATABASE_ENGINE = ‘mysql’，第一個 connection 都會下， SET NAMES utf8; 然後，之後的 Query 都會自己加 SET NAMES latin1; 大多時候，是正常，不過，有時是亂碼，奇怪就在，我把這一個有問題的結果，print 出來除錯時，螢幕是亂碼，可是在網頁上又可以變正常，真想掉眼淚

這種情形，一開始用 Sqlite 開發的時候，也沒有，所以開發環境，還是跟實際一模一樣比較好

真是很怪的情形，令我頭痛好幾個晚上，有點像是靈異現象了

不過還好試一下舊的mysql engine ，還可以用，而且不會有這種怪情形，他只有會在connection 時下， SET NAMES utf8; 之後的 Query 不會加 SET NAMES latin1

暫時用這一個好了，設定 settings.py 裡改成 DATABASE_ENGINE = ‘mysql_old’

作業環境，Debian_etch，python2.4.4，python-mysqldb-1.2.1-p2-4，mysql-server-5.0.32，Django svn 4866