Githawk: 书签重置（再次）

不仅因为我们添加了新参数。 重置发生是因为我将商店更改为使用NSMutableOrderedSet 。

这给处理数据库/迁移带来了同样的问题。 🤦‍♂️

_{使用GitHawk发送}

等待编码不能处理结构变化吗？ 那么如果我们添加一个新属性，它会无法反序列化吗？

如果是这种情况，我们不妨回到NSCoding 。

_{使用GitHawk发送}

确切地说，如果你升级你只会在控制台中得到一堆错误，说它不知道这个对象到底是什么并且失败（因此重置）

如果NSCoding处理得更好，那么可能值得改变😞

使用 NSCoding，您可以完全控制，只需将新值设为可选，或在 initWithCoding 中提供默认值。

我们应该在 1.12 之前改变这个

_{使用GitHawk发送}

所以可以用 Codable 来做到这一点，正如我上面建议的那样——但问题是没有一个默认值可以使用并且没有错误。 我的意思是，是的，您肯定可以争论“边缘情况”，但实际上我们需要一个迁移系统，该系统可以执行请求并使用新信息更新书签🤔

@Sherlouk 想到了 Spark 的“升级数据库”之类的东西

_{使用GitHawk发送}

从这个意义上说，我们已经有了错误。 当 repo 更改其默认分支时会发生什么？

听起来更像是我们需要一个系统来在您访问它们时刷新它们。

_{使用GitHawk发送}

在书签的意义上，非常真实。 问题/搜索/等都是存储库的最新参考，因此它们的信息将是正确的。

书签和最近的搜索需要一种方法来仅从所有者/名称加载存储库以在输入之前获取其他信息

哎呀，如果我们这样做了，我们就可以开始在回购和问题标签上显示星级。 可以保持简单，只有在您输入内容时才刷新（与某些同步服务相比）。

旁注，您不能在单个 gql 请求中查询多个存储库，对吗？ 所以就像一个按名称请求 4 个 repos 的请求？

_{使用GitHawk发送}

据我所知，我认为是 1:1。 星星，标签，提交信息🤔🤔

_{使用GitHawk发送}

想在这里做什么？ 想在本周提交 1.12。 我不太担心这个自动取款机，只需要考虑一个迁移计划。

听起来像长期我们只需要一个刷新机制，但这不会太难添加。

也许我们只需要稍微重构书签，以便我们可以根据标识符进行 O(1) 查找并更新对象？

我个人非常担心在没有计划的情况下发布书签，就好像我们不处理它一样，我们会继续清除用户书签！

_{使用GitHawk发送}

我们永远不会发布擦除书签的版本，我不会接受。 任何会破坏书签的更改都应该包括迁移，即使是手动的。

_{使用GitHawk发送}

关闭它，因为我认为我们现在已经控制住了。 绝对应该为每个新版本检查这个 - 或者找到某种方法来自动化它。