前情提要这篇文章基于前两篇文章Django多数据库历险记（一）、Django多数据库历险记（二），将继续讲述关于Django多数据库的历险记。好吧其实这篇文章的内容已经和Django多数据库没有太大关系了……只是为了和前两篇文章的命名保持一致才取了这个标题。 秘技：避免物理外键约束 对于数据库层面的物理外键，国内互联网上的声音普遍一致，那就是不推荐使用（比如这个知乎问题），公司的DBA也持这个态度

前情提要这篇文章基于上一篇文章Django多数据库历险记（一），将继续讲述关于Django多数据库的历险记。 在上一篇文章中，我创建了一个Django项目：multi_db，在这个项目里指定了两个app：app_1和app_2，每个app下各自创建了一个Model：Model1和Model2，并为这两个app各自分配了独立的数据库db_1和db_2。历险继续～ 第三关：TestCase在multi

前言毫无疑问，Django是最优秀的Python Web框架之一，然而其对多数据库的支持却让我内心十分复杂。在数据库迁移、跨库外键、单元测试等方面，坑无处不在。于是就有了这篇文章，关于Django多数据库的历险记。 注：本篇文章使用Python 3.6+Django 2.2 准备出发 创建Django项目multi_db和两个app：app_1和app_2 1234$ django-admin

前言 在以前的文章中，我介绍了两种分析Django视图函数性能的工具：Django Debug Toolbar和cProfile中间件。在实际开发过程中，前者的SQL执行分析是相当实用的功能。 但美中不足的是，Django Debug Toolbar只能在浏览器里分析响应类型为HTML的视图函数，这就导致响应类型为JSON的视图函数必须要借助Django Rest Framework框架中的HTM

环境准备假设有一台远程服务器：1.2.3.4，上面运行着一个socks5代理：127.0.0.1:1080。登上这台远程服务器后，可以通过curl验证这个代理： 123456$ curl --socks5 127.0.0.1:1080 https://httpbin.org/get{ ... "origin": "1.2.3.4", ...&

前言 因为一些不可描述的原因，在中国绝大多数地区进行更新APT软件包列表（apt-get update）&安装APT软件包（apt-get isntall）、拉取Docker镜像（docker pull）、安装PyPI包（pip install）等操作都是一件非常痛苦的事：网络连接速度太慢了。万幸的是我们有许多开源软件镜像站点，合理设置镜像站点能够极大提升工作和学习效率。这篇文章介绍的就是

前言ownCloud一直是市场上最受欢迎的个人云存储解决方案之一，有着使用广泛、客户端兼容性好、自由开源等优点。但ownCloud的部署涉及LAMP环境，部署过程较为繁琐。这篇文章介绍如何用docker-compose快速部署ownCloud，并配置Nginx转发+HTTPS提高服务器安全性。 配置docker-compose 以下部分内容来自ownCloud官方安装文档 首先，下载官方dock

前言用工具测试下手头用着的linux server，三个vps平台、一台物理机，测试结果看看就好，不用太较真。 测试结果汇总 服务商 Google Cloud Google Cloud 阿里云 某NAT VPS商家 个人PC 机器型号 f1-micro 1vCPU 0.6GB 10GB g1-small 1vCPU 1.7GB 40GB ecs.n4.small 1vCPU 2GiB 4

前言开源项目Kong是当下最火的API Gateway项目之一，官方也在Docker Hub上提供了Kong的镜像。但我在使用官方镜像来部署Kong的过程中发现，我需要对官方镜像做一些改动来适应我的需求： 在Docker启动时只需要给定镜像、启动命令即可完成部署（包括初次部署），方便迁移k8s； 方便Kong切换不同的配置文件； 将Kong所有的日志存放在指定目录，方便挂载存储。 这篇文章记录

前言不存在没有BUG的代码，也不存在不会出现异常的视图函数。当Django视图函数中的代码出现异常时，访问这个URL的用户就会收到状态码为500 Internal Server Error的HTTP 响应。如何捕捉视图函数里出现的异常，这是本篇文章要讨论的问题。 注：本文所使用的运行环境为uWSGI 2.0.18+Python3.6+Django 2.2 在uWSGI的日志中显示Traceba