我们有一个相当简单的基于Django的网站来进行CRUD操作。我一直在本地进行测试和开发,然后在测试完成后检查发布和数据库模式更改到实时服务器上。我们最近在发布某些类型的更改时遇到了问题。想象一下以下事件序列:
其他网站如何处理这类问题?我的想法:
思想?
答案 0 :(得分:2)
对已发布的API(或UI,在本例中)的更改总是很棘手。如果可能,请保留向后兼容性。对于大多数表单,我认为版本之间的功能不会改变。您可以添加或删除一两个字段,但这将由后端的表单验证处理。这基本上就是你在第4步中所描述的内容。我并没有真正考虑到这个问题;运行时错误从一个时间发生到另一个 - 只要您的应用程序正常处理它并通知用户该问题,那么确实没有问题。
答案 1 :(得分:1)
如果这确实是一个大问题,您可以将代码版本包含在每个表单中的某种隐藏变量中。如果提交的版本与当前运行的应用程序版本不匹配,则可能会显示正确的错误,并让他们填写表单上可能存在的任何新字段。您甚至可以更进一步,只显示表单已更改的消息。可能会根据表单的定义创建某种哈希值,并将其用作隐藏字段。如果哈希错误,您知道他们提交的表单不正确。
答案 2 :(得分:0)
如果没有在验证中编码可能会发生更新,我无法看到如何实现这一目标。例如。 “预测”提交时字段可能已更改,并相应地设置默认值/拒绝。
当维护窗口接近时,“缩减”内容提交怎么样?将受影响的用户最小化到那些已经打开浏览器的用户?
答案 3 :(得分:0)
我使用的很多网站(被授予,主要是在我的工作地点内部)宣布“我们将在周末从周六下午6:00到周日早上6:00维修。”请计划当时离开系统。“虽然它并不完美,但没有,这似乎是一个很好的方法。只需要花费足够的时间来推出新的东西,进行测试,然后根据需要回滚到旧的东西。如果您认为有必要,您可以随时设置一个简单的页面,上面写着“抱歉,我们现在无法使用”,并在停机期间将人们引导至此。一般来说,如果你不需要你最初所说的所有时间并且你早点回来(也许那些想要借口避免工作的懒人也是例外,没有人会抱怨,但无论如何他们可能都没有工作)。
答案 4 :(得分:0)
“正确”的方法是使用定义明确的视图来优雅地处理整个类的失败。如果在模型中添加一个新字段是必需的(我假设发生了什么),视图应该处理一个ValidationError异常,抛出一个友好的错误消息并将用户发送回表单( ,重新加载时,应该有新字段可用)。无论将哪些字段添加到模型中,异常都会抛出一个干净的错误并将用户重新发送回来。