Google 日历 api v3：更新受计数限制的循环系列中的所有未来事件
Google calendar api v3: update all future events in recurring series limited by count
我的问题：如何更新受计数限制的重复事件中的 "this and all future" 个实例，以便事件总数保持一致？
问题是什么：
正在尝试修改重复事件，我遵循以下指南：
https://developers.google.com/calendar/recurringevents
基本上要使用目标事件更新所有未来的重复事件，文档说需要进行两次调用：
- 更新现有活动，使其在目标活动日期之前结束
- 使用相同的字段创建一个新的周期性事件，但需要更改的字段除外。
在出现受发生次数限制的事件之前，它工作正常。
假设有一个重复发生的事件限制为 10 次，目标事件是第 5 次。
现在我需要拆分原始事件，以便前 4 个事件进入原始事件（因此我将 COUNT 从 10 更新为 4）然后我创建一个新的重复事件来保存其余 6 个事件（因此在这种情况下 COUNT 为 6 )
我的第一个观察是，这不是拆分事件在 google 日历中的显示方式 - 如果我手动测试，这两个事件仍然显示 10 次，但第二个事件不会产生任何额外的结果事件（从开发人员的角度来看，我预计有 14 个事件，但正如任何用户所期望的那样，有 10 个事件）。这意味着这里有不同的方法？是吗？
此外，如果我最终手动计算事件的数量，仍然存在一些问题，例如先删除一个事件（比方说，第 4 个事件）- 现在我怎么知道我需要显示 6新实例中的实例而不是 7 个？
这些想法让我觉得有更好的方法，但我找不到任何其他选择。有什么建议吗？
更新
似乎 google 的做法有所不同：例如，在日历视图中更改 "this and future" 事件的标题后，它似乎不会产生两个不同的重复事件，因为如果您尝试删除 "all" 个事件，这将完全删除所有事件（而不是只删除一个块，在目标事件之前或之后）
他们好像在制造一堆例外，或者 "recurring exception" 之类的。到目前为止，找不到任何关于如何做到这一点的例子。
经过几天的研究后找不到任何好的解决方案，虽然我需要继续前进，但我最终在 "good enough UX for my case" 和 [=28= 之间找到了一种 "compromise" ].
所以我最终单独更新了每个事件，这违反了 google's warning 如下所示，但我将最大计数限制为 50。这不是其他人想要做的，但这已经足够了我的应用程序中的真实世界用例。
Warning: Do not modify instances individually when you want to modify
the entire recurring event, or "this and following" instances. This
creates lots of exceptions that clutter the calendar, slowing down
access and sending a high number of change notifications to users.
如果用户需要安排更多时间，则要求用户改用 "end date"。
再说一次，无论如何都不理想，所以如果有人知道如何正确处理或知道如何 google 处理，非常欢迎您分享！ （嗯......我现在也需要它来展望......）
UPDATE：刚刚有了一个想法：作为一项改进，可以根据索引编辑 "all future events" 或主事件 + "all previous events"的目标事件。在这种情况下，可以将请求数限制为 2（因此在 50 个事件的情况下，我最多需要执行 25 个请求）
因此，如果用户想要将标题从 "Hello" 更改为 "Goodby"，并且如果用户选择了 50 个事件系列中的第 5 个事件来更改所有未来的事件，我们可以更改 master将事件更改为 "Goodby" 这将更改所有事件的标题，然后将前 4 个事件更新为原始 "Hello"。
评论和聊天的强制摘要：
更新事件：
要更新重复事件中的特定事件，您需要通过指定事件实例 ID 来更新单个实例。
这只是与日期时间戳连接的事件 ID（您可以在为您的事件 ID 发出 Events: instances 请求时看到这一点；如果您的事件 ID 是 xxxxxxxxxxxx，那么实例 ID 将是像 xxxxxxxxxxxx__20200603T170000Z).
遗憾的是，没有直接的更新实例端点，因此要在一个请求中更新多个实例，您需要使用 batching
API 没有专门的方法来更新重复发生的事件，无论重复类型如何，我想这就是文档说要通过删除和插入来编辑以前的重复发生事件的原因一个新的，根据 Google's warning:
Do not modify instances individually when you want to modify the entire recurring event, or "this and following" instances. This creates lots of exceptions that clutter the calendar, slowing down access and sending a high number of change notifications to users.
批处理：
对事件实例进行批量更新确实可以保持计数的一致性。如果您批量编辑实例，然后在删除重复事件的一个实例时使用 'this and all future events' 选项，它们 do 都会被删除，因为它们仍然是复发。在这两种情况下都没有创建新事件，正在更改事件实例。
如果您尝试 Events: instances and use Events: update 以仅更改事件的某些实例，那么您会发现它们都属于同一个循环链并且没有计数更改。
对于任意大量计数，即使您有一个包含 9999999 个实例的重复事件，每个事件仍然有一个 ID，您可以从 Events: instances 中检索该 ID。它存储为单个事件以供事件使用，但实例的 ID 是不同的标识符。
老实说，您必须手动编辑每一个都不是很好；对于像 9999999 这样的大量计数，它基本上是不可行的，因为您必须为要更改的每组 100 个实例发出批处理请求，但这是目前通过 API 唯一可用的选项。
功能请求：
但是，您可以让 Google 知道这是一项对日历 API 很重要的功能，并且您希望请求他们实现它。 Google 的 Issue Tracker 是开发人员报告问题和为他们的开发服务提出功能请求的地方，我强烈建议您在那里提出功能请求，Calendar API 功能请求表可以是找到 here.
我的问题：如何更新受计数限制的重复事件中的 "this and all future" 个实例，以便事件总数保持一致？
问题是什么：
正在尝试修改重复事件，我遵循以下指南：
https://developers.google.com/calendar/recurringevents
基本上要使用目标事件更新所有未来的重复事件，文档说需要进行两次调用：
- 更新现有活动，使其在目标活动日期之前结束
- 使用相同的字段创建一个新的周期性事件，但需要更改的字段除外。
在出现受发生次数限制的事件之前，它工作正常。
假设有一个重复发生的事件限制为 10 次，目标事件是第 5 次。 现在我需要拆分原始事件，以便前 4 个事件进入原始事件（因此我将 COUNT 从 10 更新为 4）然后我创建一个新的重复事件来保存其余 6 个事件（因此在这种情况下 COUNT 为 6 )
我的第一个观察是，这不是拆分事件在 google 日历中的显示方式 - 如果我手动测试，这两个事件仍然显示 10 次，但第二个事件不会产生任何额外的结果事件（从开发人员的角度来看，我预计有 14 个事件，但正如任何用户所期望的那样，有 10 个事件）。这意味着这里有不同的方法？是吗？
此外，如果我最终手动计算事件的数量，仍然存在一些问题，例如先删除一个事件（比方说，第 4 个事件）- 现在我怎么知道我需要显示 6新实例中的实例而不是 7 个？
这些想法让我觉得有更好的方法，但我找不到任何其他选择。有什么建议吗？
更新
似乎 google 的做法有所不同：例如，在日历视图中更改 "this and future" 事件的标题后，它似乎不会产生两个不同的重复事件，因为如果您尝试删除 "all" 个事件，这将完全删除所有事件（而不是只删除一个块，在目标事件之前或之后）
他们好像在制造一堆例外，或者 "recurring exception" 之类的。到目前为止，找不到任何关于如何做到这一点的例子。
经过几天的研究后找不到任何好的解决方案，虽然我需要继续前进，但我最终在 "good enough UX for my case" 和 [=28= 之间找到了一种 "compromise" ].
所以我最终单独更新了每个事件，这违反了 google's warning 如下所示，但我将最大计数限制为 50。这不是其他人想要做的，但这已经足够了我的应用程序中的真实世界用例。
Warning: Do not modify instances individually when you want to modify the entire recurring event, or "this and following" instances. This creates lots of exceptions that clutter the calendar, slowing down access and sending a high number of change notifications to users.
如果用户需要安排更多时间，则要求用户改用 "end date"。
再说一次，无论如何都不理想，所以如果有人知道如何正确处理或知道如何 google 处理，非常欢迎您分享！ （嗯......我现在也需要它来展望......）
UPDATE：刚刚有了一个想法：作为一项改进，可以根据索引编辑 "all future events" 或主事件 + "all previous events"的目标事件。在这种情况下，可以将请求数限制为 2（因此在 50 个事件的情况下，我最多需要执行 25 个请求）
因此，如果用户想要将标题从 "Hello" 更改为 "Goodby"，并且如果用户选择了 50 个事件系列中的第 5 个事件来更改所有未来的事件，我们可以更改 master将事件更改为 "Goodby" 这将更改所有事件的标题，然后将前 4 个事件更新为原始 "Hello"。
评论和聊天的强制摘要：
更新事件：
要更新重复事件中的特定事件，您需要通过指定事件实例 ID 来更新单个实例。
这只是与日期时间戳连接的事件 ID（您可以在为您的事件 ID 发出 Events: instances 请求时看到这一点；如果您的事件 ID 是 xxxxxxxxxxxx，那么实例 ID 将是像 xxxxxxxxxxxx__20200603T170000Z).
遗憾的是，没有直接的更新实例端点，因此要在一个请求中更新多个实例，您需要使用 batching
API 没有专门的方法来更新重复发生的事件，无论重复类型如何，我想这就是文档说要通过删除和插入来编辑以前的重复发生事件的原因一个新的，根据 Google's warning:
Do not modify instances individually when you want to modify the entire recurring event, or "this and following" instances. This creates lots of exceptions that clutter the calendar, slowing down access and sending a high number of change notifications to users.
批处理：
对事件实例进行批量更新确实可以保持计数的一致性。如果您批量编辑实例，然后在删除重复事件的一个实例时使用 'this and all future events' 选项，它们 do 都会被删除，因为它们仍然是复发。在这两种情况下都没有创建新事件，正在更改事件实例。
如果您尝试 Events: instances and use Events: update 以仅更改事件的某些实例，那么您会发现它们都属于同一个循环链并且没有计数更改。
对于任意大量计数，即使您有一个包含 9999999 个实例的重复事件，每个事件仍然有一个 ID，您可以从 Events: instances 中检索该 ID。它存储为单个事件以供事件使用，但实例的 ID 是不同的标识符。
老实说，您必须手动编辑每一个都不是很好；对于像 9999999 这样的大量计数，它基本上是不可行的，因为您必须为要更改的每组 100 个实例发出批处理请求，但这是目前通过 API 唯一可用的选项。
功能请求：
但是，您可以让 Google 知道这是一项对日历 API 很重要的功能，并且您希望请求他们实现它。 Google 的 Issue Tracker 是开发人员报告问题和为他们的开发服务提出功能请求的地方，我强烈建议您在那里提出功能请求，Calendar API 功能请求表可以是找到 here.