Question

这是一个相当绊脚石。警告：以下不是问题，而是对我提出的问题的解释。我的问题是 - 你有更好的方法吗？是否有一些我不熟悉的常用技巧？似乎这是一个微不足道的问题。

所以你有任务模型。您可以创建任务，完成任务，销毁它们。然后你有重复的任务。它就像常规任务一样，但它附有一个重复规则。但是，任务可以无限期地重复 - 您可以在计划中提前一年，并且您应该看到任务显示。

因此，当用户创建定期任务时，您不希望在未来的一百年内构建数千个任务，并将它们保存到数据库中，对吧？所以我开始思考 - 你是如何创造它们的？

一种方法是在查看日程安排时创建它们。因此，当用户提前一个月移动时，将创建任何重复任务。当然，这意味着您不能再简单地处理任务的数据库记录。您执行的任务上的每个SELECT操作都必须位于特定日期范围的上下文中，以便触发该日期范围内的重复任务。这是一种维护和性能负担，但可行。

好吧，但原来的任务怎么样？每个周期性任务都与创建它的重复规则相关联，并且每个重复规则都需要知道开始重复的原始任务。后者很重要，因为当用户浏览他们的日程安排时，您需要将原始任务克隆到新日期。我猜也是可行的。

但是如果更新原始任务会发生什么？这意味着现在，当我们浏览计划时，我们将创建从修改的任务克隆的重复任务。那是不可取的。所有隐式持久的重复任务都应该显示添加重复时原始任务的样子。因此，我们需要单独存储原始任务的副本，并从中进行克隆，以便重复工作。

但是，当用户在计划中导航任务时，我们如何知道在特定点是否需要创建新的重复任务？我们问复发规则：“嘿，我今天应该继续执行任务吗？”它说是或否。如果今天已经有这个重复的任务，我们不会创建一个。一切都很好，除了用户还应该能够简单地删除一个自动持久的重复任务。在这种情况下遵循我们的逻辑，系统将重新创建已删除的任务。不好。因此，这意味着我们需要继续存储任务，但将此标记为已删除的任务以进行此重复。 MEH。

正如我在开始时所说，我想知道其他人是否解决了这个问题并且可以在这里提供建筑建议。它必须是这个混乱吗？还有什么比我更缺的优雅吗？

更新：由于这个问题难以完美回答，我将批准对设计/架构最有帮助的见解，这对于此类问题具有最佳的帮助/权衡比率。它不必包含所有细节。

Answer 1

我知道这是一个古老的问题，但我刚刚开始研究这个问题，我发现Martin Fowler的这篇论文阐明了：Recurring Events for Calendars

我的主要内容是使用他所谓的“时态表达式”来确定预订是否属于某个日期范围而不是尝试将无限数量的事件（或您的案例任务）插入到数据库中。

实际上，对于您的用例，这可能意味着您使用名为schedule的“临时表达式”属性存储任务。 ice_cube recurrence gem能够将自身序列化为活动记录属性like so：

class Task < ActiveRecord::Base
  include IceCube
  serialize :schedule, Hash

  def schedule=(new_schedule)
    write_attribute(:schedule, new_schedule.to_hash)
  end

  def schedule
    Schedule.from_hash(read_attribute(:schedule))
  end
end

Ice cube看起来非常灵活，甚至允许您指定重复规则的例外。（假设您只想删除一次任务，但不是全部。）

问题在于，您无法真正在数据库中查询属于特定日期范围的任务，因为您只存储了创建任务的规则，而不是任务本身。对于我的情况，我正在考虑添加一个像“next_recurrence_date”这样的属性，用于做一些基本的排序/过滤。您甚至可以使用它将任务放在队列中，以便在下一个重复日期完成某些操作。（比如检查该日期是否已经过去，然后重新生成它。您甚至可以在下一个重复日期过后存储任务的“已归档”版本。）

这解决了“如果任务更新会怎样”的问题，因为任务在过去之前都不会持续存在。

无论如何，我希望这对有人试图通过他们自己的应用程序来帮助。

Answer 2

为内部社交网络应用程序完成了类似日历的组件，这是我解决该问题的方法。

略微背景：我需要为整个公司预订董事会会议。每个会议室都需要以一次性或定期的方式预订。正如你所发现的，这是一种杀死你的复发规则。我的问题的另一个转折点是可能存在冲突，即两个人可能会尝试在相同的日期和时间预订相同的会议室。

我将模型拆分为Boardroom（显然）和Event（与用户关联的预订）。我认为还有一个连接模型，但它已经有一段时间了。当用户尝试预订会议室时，这是一个过程：

尝试在第一个可用日期预订（由用户通过日历用户界面完成，类似于Google日历创建活动的方式）
如果是一次性的，你就完成了
如果是经常性事件，请尝试根据给出的规则（每周，每两周，每月）立即预订接下来的6个事件;如果由于冲突而失败，请预订可以通过电子邮件将冲突发送给用户
预订明年或直到重复在后台工作结束的日期;遵循＃3

在解决冲突时，用户可以选择根据具体情况解决冲突，也可以将剩余的预订移至新的可用日期和时间。

如果用户更新了原始预订（例如更改了时间和日期），则他/她可以选择仅更新该一次或每次重复。如果选择后者，则在删除现有事件后重新调用步骤3和4。

如果这听起来很像谷歌日历，那么你完全理解我的方法，:)）

希望这有帮助。

Answer 3

我个人认为（在我熟悉的python中）和ruby（我知道的不太好，但它是一种动态语言，所以我认为概念图1：1），你应该使用生成器。这是一个简约的回答怎么样？现在，当您生成UI时，您将传递对生成器的引用，并根据请求生成所需的对象。

作为一个接口，它有下一个项目和前面的项目方法，并且有点像一个可以在各种交互中向前和向后跋涉的游标。事实上，它是一段伪装成无限系列（数组）而不使用无限内存的代码。

为什么需要扩散物体？您真正需要的是虚拟数据显示控件（对于Web或桌面），我认为，在网络环境中也称为“分页”，您可以将您的日程安排视为无限的按需生成电子表格，没有顶行，并没有底线。您需要能够计算（计算，而不是存储）的唯一值是现在出现的值，对用户可见。

在计划中建模无限期重复任务（类似日历的rails应用程序）

3 个答案: