最终用户在Rails ActiveRecord模型中更新枚举

在以下方案中寻找最佳策略。最终用户在Rails ActiveRecord模型中更新枚举

考虑轨道4,5网上商店的应用程序，具有带有状态

class Order 
    enum status: [ :placed, :processed, :shipped ] 
end

我们运送的应用给客户，并在一个月后，他们回来对我们说的要添加一个多状态模型订单 - 延期交货。我们进入并更新代码/测试/部署。

class Order 
    enum status: [ :placed, :processed, :shipped, :backordered ] 
end

几个月后，他们再次回来，想要一个更多的状态 - ：work_in_progress。等

在我们由具有骨料模型可以避免这个问题过去 - 状态 - 这将是一个STI模型和持物像

OrderStatus < Status

和

CustomerStatus < Status

这使得是平凡的客户添加状态或更改状态的名称，但它会导致更慢的SQL查找和繁琐的连接，特别是在复杂查询中。

所以我想知道是否有处理这个问题的好策略？现在我们有两个组合 - 在模型上我们不认为客户想要添加/删除状态 - 我们保持枚举状态，否则我们将属于某种状态/类别模型。

来源

2014-10-03 konung

一个月后他们回来对我们说的要添加一个更状态

修改一行代码，即使它发生每月一次，不应该是痛苦的经验。你已经有了最好的策略：当客户要求改变时，咬紧牙关，增加新的价值，测试和部署。如果这太繁重，我会说问题在于部署过程而不是客户。

经过几轮这个客户将用完新的价值添加并转移到其他烦人的请求。

来源

2014-10-03 21:39:33 zetetic

:-)我想我太具体了。假设您正在创建一个开源的rails商店应用程序，这将被数百个用户使用。或者你的客户不想为每一件小事回到你身边。在这种情况下，我更像是一个程序员，而不是一个人的人 - 我宁愿不与一个客户打交道，而只是增加一个新的状态。我的直觉是有一个更好的方法。没有？ – konung 2014-10-03 21:56:24

够公平的。如果更改频繁或多次，您将采用另一种方法。我在这里看不到任何灵丹妙药：你为更复杂的模型关联交换枚举的简单性，并需要验证/消毒用户输入。 – zetetic 2014-10-03 22:02:17

这是我达成的逻辑结论。我想我的直觉是错的。 :-)只是想检查它。我会把它打开几天，如果没有人提出一个更好的建议将标记它的答案。谢谢zetetic – konung 2014-10-04 17:35:57

最终用户在Rails ActiveRecord模型中更新枚举

回答

相关问题