什么方法最适合在 Django 中映射以年份命名的遗留应用程序表?
更好地看看表名是什么样的:
- 2009_articles
- 2010_articles
- 2011_articles
- 2009_customers
- 2010_customers
- 2011_customers
- 2009_invoices
- 2010_invoices
- 2011_invoices
开发人员已经模拟了某种分区(早在 mysql 支持它之前),但现在它破坏了任何制作快速前端的尝试,所以客户可以查看他们的发票并切换年份。
几个月后,我得到以下结果:
更改 Invoice._meta.db_table 是无用的,因为 ORM 推导的任何其他关系都是错误的
models.py无法获取请求变量
选项a: 使用抽象模型,因此Invoice10添加了meta.db_table=2010并继承自Invoice模型,Invoice11添加了meta.db_table=2011,而不是DRY虽然应用程序不需要同时支持超过两三年,但我仍然必须检查
选项b: 重复模型并更改我的视图中的导入: 如果年份 == 2010: 从模型导入 Article10 作为 Article
等等
选项 c: 网上很多地方都提到了动态模型,但是当我只需要模型动态的 1% 部分时,为什么要使用 100% 动态模型呢?
选项d: 哇,沮丧之后简直要疯了。多个数据库设置和使用路由器怎么样?
任何帮助将不胜感激。
Better see what the table names look like:
- 2009_articles
- 2010_articles
- 2011_articles
- 2009_customers
- 2010_customers
- 2011_customers
- 2009_invoices
- 2010_invoices
- 2011_invoices
Developers have simulated some kind of partitioning (long before mysql supported it) but now it breaks any try to make a quick frontend so customers can see their invoices and switch years.
After a couple on months I have the following results:
Changing Invoice._meta.db_table is useless cause any other relation deduced by the ORM will be wrong
models.py cannot get request variables
Option a:
Use abstract models so Invoice10 adds meta.db_table=2010 and inherits from Invoice model, and Invoice11 adds meta.db_table=2011, Not DRY although the app shouldn't need to support more than two or three years at the same time, but I will have to still check if
Option b:
Duplicate models and change imports on my views:
if year == 2010:
from models import Article10 as Article
and so on
Option c:
Dynamic models as referred to in several places on the net, but why have a 100% dynamic model when I just need a 1% part of the model dynamic?
Option d:
Wow, just going crazy after frustration. What about multiple database settings and use a router?
Any help will be much appreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
选项 e:创建新的相关模型/数据库结构,并在新结构中导入旧数据。
Option e: create new relevant models/database structure, and do an import of the old data in the new structure.
丑陋,但必须告知。
我通过使用 Django signal: class_prepared 和 ThreadLocal 来获取会话,实现了一些有用的功能:
映射多个相同数据库表(invoices_01_2013、invoices_02_2013,...)的模型类也是如此,具体取决于应用程序用户浏览的月份和年份。
生产中工作良好。
Ugly, but must inform.
I achieved something useful by using Django signal: class_prepared and ThreadLocal to get session:
So is one model class mapping several identical database tables (invoices_01_2013, invoices_02_2013, ...) depending of what month and year the application user is browsing.
Working fine in production.