摘要:默认对此没有很好的支持数据库结构是由另一个工具管理的,并没有直接修改数据库结构的权限。第二个思路是利用的多数据库支持。由于使用后台的用户基本上只有公司内部的业务人员,数据量不会大,用服务器级的数据库有牛刀之嫌。
在多数项目中,总有一些几乎一成不变的 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 潜在的问题在于不够现代化的界面,以及深度定制较为困难。不过对于我们的后台应用来说,这些都是可以接受的代价。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/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