摘要:默認對此沒有很好的支持數據庫結構是由另一個工具管理的,并沒有直接修改數據庫結構的權限。第二個思路是利用的多數據庫支持。由于使用后臺的用戶基本上只有公司內部的業務人員,數據量不會大,用服務器級的數據庫有牛刀之嫌。
在多數項目中,總有一些幾乎一成不變的 CRUD 操作,編寫這些代碼很無聊,但又是整個系統必不可少的功能之一。我們在上一個項目中也面臨類似的問題,雖然已經實現了一個功能相對完整的管理后臺,也盡量做到了代碼復用,但隨著項目規模的增長,需要編寫的樣本代碼也不斷膨脹,占用了大量開發時間。
面對這種局面,我自然想到了 Django。要知道, Django Admin 幾乎就是為這種需求量身定制的。但對于我們的項目而言,還有幾個問題要解決:
我們的數據庫使用 SQL Server。Django 默認對此沒有很好的支持;
數據庫結構是由另一個工具管理的,Django 并沒有直接修改數據庫結構的權限。因*
此,我們不能使用 Django migrate;
出于同樣的理由,我們無法在數據庫中創建 Django Admin 內置要求的數據表(包括 auth/session 等)。
下面我們來解決這些問題。如果你碰到類似情況的話,可以參考本文的做法。
遺憾的是,針對 Django 開發的 SQL Server 適配器雖然有幾種,但都比較古老了,對新版的 Django 支持存在問題。經過嘗試,我們選擇了?Django-Mssql,雖然功能是可用的,但該庫只支持到 Django 1.8,經測試,對 Django 1.11 不兼容,Django 2.x 就更不行了。好在我們并不需要很新的功能,因此就用 virtualenv 鎖定版本了:
Django==1.8 django-mssql==1.8 pywin32==223
??在這里還是要推薦下我自己建的Python開發學習群:725479218,群里都是學Python開發的,如果你正在學習Python ,小編歡迎你加入,大家都是軟件開發黨,不定期分享干貨(只有Python軟件開發相關的),包括我自己整理的一份2018最新的Python進階資料和高級開發教程,歡迎進階中和進想深入Python的小伙伴
django-mssql 是 Windows 版的庫,幕后使用了 ADO 為驅動,因此同時還要安裝 pywin32。
針對第二和第三個問題基本上有兩個思路。第一個是通過實現自定義的 Backend 來跳過 Django 內置的、基于數據庫的實現。從原理上來講是行得通的,但簡單嘗試了一下,發現要自定義的部分相當多,工作量太大。總之,這條路不是很可取。
第二個思路是利用 Django 的多數據庫支持。既然業務數據庫不可由 Django 來管理,那么就再用一個數據庫來支持 Django 的基本功能,而 Django 對業務數據庫只作查詢和更新,不執行 migrate。當然,為了使用多個數據庫,我們需要在配置上多做一些工作。由于使用后臺的用戶基本上只有公司內部的業務人員,數據量不會大,用服務器級的數據庫有牛刀之嫌。處于簡便考慮,這里使用默認的 SQLite 作為內置數據庫:
DATABASES = { "default": { "ENGINE": "django.db.backends.sqlite3", "NAME": os.path.join(BASE_DIR, "db.sqlite3"), }, "mydb": { "ENGINE": "sqlserver_ado", "HOST": "127.0.0.1", "NAME": "", "USER": " ", "PASSWORD": " ", "OPTIONS": { "provider": "SQLOLEDB", } } }
需要說明,Django-mssql 為 provider 選項提供的默認值(按照官方文檔應為 SQLCLI10)實測會導致出現“找不到提供程序” 的錯誤。由于 provider 的設置取決于 ADO 的注冊信息,不一定在所有機器上都相同,所以你可能需要自己測試決定哪個選項可用。
現在我們配置了兩個數據源,但還需要告訴 Django 它們和模型的對照關系。實現這一點可以在語句/實體/全局等多種級別定義。對于我們的需求而言,對應關系是固定的,逐個模型定義并無必要,通過全局定義是最簡單的。實現這一定義的對象在 Django 的術語中稱為數據庫路由(Database Router)。首先在 settings.py 中定義類名:
DATABASE_ROUTERS = ["project.db.MyAppRouter"]
然后完成類的實現:
class MyAppRouter: def db_for_read(self, model, **hints): if model._meta.app_label == "myapp": return "myapp" return None def db_for_write(self, model, **hints): if model._meta.app_label == "myapp": return "myapp" return None def allow_relation(self, obj1, obj2, **hints): return None def allow_migrate(self, db, app_label, model_name=None, **hints): return False
數據路由需要按照 Django 的要求實現四個方法。其中主要是讀寫兩個方法,我們需要根據傳來的模型決定匹配到哪個數據源。 其他兩個方法目前意義不大,按照默認的實現即可。
定義模型配置到此完成,接下來需要創建模型。對于已經存在的數據表,可以用管理命令 inspectdb 反向生成代碼,減少一些手工輸入的負擔。但生成的代碼未必完全符合你的要求,所以還是應該自己檢查一下。對于 SQL Server,如果主鍵名不是默認的 id,那么 inspectdb 似乎不會自動識別到它們,所以我們需要檢查一下主鍵字段有無 primary_key,如果沒有的話就加上。
python manage.py inspectdb --database=myapp > myappmodels.py
為了方便調試和辨別記錄,一般來說我們還要為模型類加上 verbose_name 并重載內置的字符串方法。
class XXModel(models.Model): XXId = models.BigIntegerField(primary_key=True) ... class Meta: managed = False db_table = "XXModel" verbose_name = "模型名稱" verbose_name_plural = "模型名稱" def __str__(self): return self.XXField
把模型添加到 admin,對應的后臺管理信息就完成了。
admin.site.register(XXModel, XXAdmin)運行程序
最后,為內置數據庫生成必要的表,創建管理員賬戶,即可運行程序。以下命令就無需說明了:
$ python manage.py migrate $ python manage.py createsuperuser $ python manage.py runserver總結
我們第一個版本的后臺程序是自己手工編碼完成的,用了大概兩周的時間。問題在于,每增加一個模型都要手工添加大量樣本代碼。而改寫成 Django 只用了一天時間,包括熟悉相關資料和使用方法,增加一個模型只需花幾分鐘。這也是為什么很多了解 Django 的開發者轉移到其他平臺以后,會尋找類似的項目。就我了解的范圍,Spring Boo 和 Django 在概念上比較類似,但 Boo 主要走的是代碼生成的路線,復雜度更高,理論上靈活性也應該更好一些(我沒有深度研究過)。Nodejs 社區有 Keystone.js 和 Sails.js,不過前者專門針對 MongoDB,后者支持多種數據庫后端,但風聞最近有停止開發的跡象。.Net 社區以前有一個 DynamicData,現在似乎也沒了下文。發展多年的 Django 也應該算是同類產品中最成熟、生態也最為完整的產品了。
Django 潛在的問題在于不夠現代化的界面,以及深度定制較為困難。不過對于我們的后臺應用來說,這些都是可以接受的代價。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/41900.html
摘要:默認對此沒有很好的支持數據庫結構是由另一個工具管理的,并沒有直接修改數據庫結構的權限。第二個思路是利用的多數據庫支持。由于使用后臺的用戶基本上只有公司內部的業務人員,數據量不會大,用服務器級的數據庫有牛刀之嫌。 在多數項目中,總有一些幾乎一成不變的 CRUD 操作,編寫這些代碼很無聊,但又是整個系統必不可少的功能之一。我們在上一個項目中也面臨類似的問題,雖然已經實現了一個功能相對完整的...
摘要:在模型中添加是完全可選的,所有選項都不是必須的。一個模型的數據庫表名稱,由這個模型的應用名和模型類名稱之間加上下劃線組成。使用來表示隨機排序。默認值為這個選項為時可以對數據庫表進行或刪除等操作。 Django模型理論知識 簡介 Django模型所在的位置: URL--->視圖--->模型(mysql) 什么是模型: 模型就是數據的唯一的&權威的信息源 包含所存儲的詩句的必要字段和...
摘要:數據科學項目的完整流程通常是這樣的五步驟需求定義數據獲取數據治理數據分析數據可視化一需求定義需求定義是數據科學項目和數據科學比賽的最大不同之處,在真實情景下,我們往往對目標函數自變量約束條件都并不清晰。 概述 和那些數據科學比賽不同,在真實的數據科學中,我們可能更多的時間不是在做算法的開發,而是對需求的定義和數據的治理。所以,如何更好的結合現實業務,讓數據真正產生價值成了一個更有意義的...
閱讀 3510·2021-11-25 09:43
閱讀 1266·2021-09-08 09:45
閱讀 2643·2021-09-07 09:59
閱讀 1502·2021-08-09 13:45
閱讀 3339·2019-08-30 15:54
閱讀 696·2019-08-29 18:35
閱讀 513·2019-08-29 17:18
閱讀 992·2019-08-29 14:10