Google calendar api v3：更新重复系列中的所有未来事件，受计数限制答案

【问题标题】：Google calendar api v3: update all future events in recurring series limited by countGoogle calendar api v3：更新重复系列中的所有未来事件，受计数限制
【发布时间】：2020-05-18 15:42:32
【问题描述】：

我的问题：如何在受计数限制的重复事件中更新“这个和所有未来”实例，以使事件总数保持一致？

有什么问题：

尝试修改重复事件，我遵循以下指南：

https://developers.google.com/calendar/recurringevents

基本上要使用目标事件更新所有未来的重复事件，文档说需要进行两次调用：

更新现有事件以使其在目标事件日期之前结束
使用相同的字段创建一个新的定期事件，但需要更改的除外。

在发生受发生次数限制的事件之前，它可以正常工作。

假设有一个重复发生的事件限制为 10 次，目标事件是第 5 次事件。现在我需要拆分原始事件，以便前 4 个事件转到原始事件（因此我将 COUNT 从 10 更新为 4），然后创建一个新的重复事件来保存其余 6 个事件（因此 COUNT 在这种情况下为 6 )

我的第一个观察是，这不是拆分事件在谷歌日历中的显示方式 - 如果我手动测试，这两个事件仍然显示 10 次，但第二个不会产生任何额外的事件（我希望从开发人员的角度来看有 14 个事件，但正如任何用户所期望的那样有 10 个）。这意味着这里有不同的方法吗？是吗？

此外，如果我最终手动计算事件的数量，仍然存在一些问题，例如首先删除一个事件（比如说第四个事件） - 现在我怎么知道我需要显示 6 个实例新的而不是 7？

这些想法让我觉得有更好的方法，但我找不到任何其他选择。对此有何建议？

更新

Google 的做法似乎有所不同：例如，在日历视图中更改“此和未来”事件的标题后，它似乎不会产生两个不同的重复事件，因为如果您尝试删除“所有”事件，这将完全删除所有这些（而不是只删除一个块，无论是在目标事件之前还是之后）

似乎他们正在创建一堆异常，或者可能是“重复异常”或这样做的东西。到目前为止，找不到任何关于如何做到这一点的示例。

【问题讨论】：

用 UNTIL 代替 COUNT 怎么样？因此，您可以将所有事件更新到某个日期，然后从那里创建其余事件。
感谢@Jescanellas。我想这可能会从技术角度解决它。只需要获取所有实例来获取结束日期（如果 COUNT 很大，这可能是另一个极端情况）。尽管我认为从 UX 角度来看这将是出乎意料的——如果用户设置了 10 个事件，他们希望坚持使用该类型而不是将其切换为日期（例如，如果他们需要添加更多事件，他们只需更改原始计数）。谷歌仍然很好地处理了这一点。用更多观察更新了我的问题 - 也许这可能会带来一些额外的启示。
我理解并同意您的做法。您是否介意分享一个简单的 sn-p，说明您如何更新 1 到 4 事件，然后是 5 到 10？您是否通过先前对实例的调用获得了第 5 个事件？谢谢。
感谢@Jescanellas。这实际上是我想要弄清楚的——我该如何编码。但是为了给你更多的背景信息，我总是从“现在”和主实例中获得接下来的 5 个实例。因此，当我按照上面的教程进行操作时，我应该使用 googleapi nodejs 库中的“events.update”和“events.insert”方法将其中一个实例用作目标事件。但是从我的问题中深入挖掘会发现这个问题。不确定这是否有帮助，所以请告诉我是否可以提供任何其他详细信息。
要更新重复事件中的特定事件，您需要通过指定事件实例 ID 来更新单个实例。这只是与日期时间戳连接的事件 ID（您可以在为您的 eventID 发出 events: instances 请求时看到这一点；如果您的事件 ID 是 xxxxxxxxxxxx，那么实例 ID 将类似于 xxxxxxxxxxxx__20200603T170000Z）。这是使用 UI 更新实例的方式，但没有直接的 update-instances 端点，因此要在一个请求中更新多个实例，您需要使用 batching

标签： google-calendar-api

【解决方案1】：

经过几天的研究，找不到任何好的解决方案，虽然我需要继续前进，但我最终在“对我的案例足够好的用户体验”和“打破最佳实践”之间做出了某种“妥协” .

所以我最终单独更新了每个事件，这与 google's warning 不符，如下所示，但我将最大计数限制为 50。这不是其他人想要做的，但这对于现实世界的用例来说已经足够了在我的应用中。

警告：当您要修改实例时，请勿单独修改整个重复事件，或“这个和后续”实例。这创建了许多使日历混乱的异常，放慢了速度访问并向用户发送大量更改通知。

如果用户需要安排更多时间，则要求用户改用“结束日期”。

同样，无论如何都不理想，所以如果有人知道如何正确处理或知道谷歌如何处理，非常欢迎您分享！（嗯……我现在也需要它来用于前景……）

更新：刚刚有了一个想法：作为一项改进，可以根据目标事件的索引编辑“所有未来事件”或主事件+“所有先前事件”。在这种情况下，可以将请求数限制为 2（所以如果有 50 个事件，我最多需要执行 25 个请求）

因此，如果用户想要将标题从“Hello”更改为“Goodby”，并且如果用户选择了 50 个事件系列中的第 5 个事件来更改所有未来事件，我们可以将主事件更改为“Goodby”，这将更改所有事件的标题，然后将前 4 个事件更新为原来的“Hello”。

【讨论】：

【解决方案2】：

cmets和聊天的必修课：

更新事件：

要更新重复事件中的特定事件，您需要通过指定事件实例 ID 来更新单个实例。

这只是与日期时间戳连接的事件 ID（您可以在为您的 eventID 发出Events: instances 请求时看到这一点；如果您的事件 ID 是 xxxxxxxxxxxx，那么实例 ID 将类似于 xxxxxxxxxxxx__20200603T170000Z） .

不幸的是，没有直接的 update-instances 端点，因此要在一个请求中更新多个实例，您需要使用 batching

无论重复类型如何，API 都没有用于更新重复事件的专用方法，我认为这就是文档中说通过削减并插入新事件来编辑以前的重复事件的原因，按照Google's warning:

当您要修改整个重复事件或"this and following" 实例时，请勿单独修改实例。这会产生大量异常，使日历变得混乱，降低访问速度并向用户发送大量更改通知。

批处理：

对事件实例进行批量更新确实可以保持计数的一致性。如果您批量编辑实例，然后在删除重复事件的其中一个实例时使用“此事件和所有未来事件”选项，它们确实都会被删除，因为它们仍然是复发。在这两种情况下都没有创建新事件，正在更改事件实例。

如果您使用Events: instances 并使用Events: update 仅更改事件的某些实例，那么您会看到它们都保留在同一重复链中，并且计数没有变化。

对于任意大计数，即使您有一个包含 9999999 个实例的重复事件，每个事件仍然有一个 ID，您可以从 Events: 实例中检索该 ID。它存储为单个事件以供事件使用，但实例的 ID 是不同的标识符。

老实说，您必须手动编辑每一个都不是很好；对于像 9999999 这样的大计数，这基本上是不可行的，因为您必须为要更改的每组 100 个实例发出批处理请求，但这是目前通过 API 可用的唯一选项。

功能要求：

但是，您可以让 Google 知道这是一项对日历 API 很重要的功能，并且您希望请求他们实施该功能。 Google 的问题跟踪器是开发人员报告问题并为其开发服务提出功能请求的地方，我强烈建议您在那里提出功能请求，可以找到日历 API 功能请求表here。

【讨论】：