更改firebase数据模型（同时生产多个应用程序版本）

Question

在生产中有多个版本的iOS应用程序时，更改Firebase数据模型的最佳方式是什么？

由于中间没有“应用程序服务器”层，数据库模型中的任何更改都可能会破坏应用程序的旧版本。问题的

性能相关的例子：

在1.0，我天真地保持与下“/职位/”后一切版本。现在，在2.0版本中，我希望采用Firebase的建议并添加“/ user-post”端点以快速列出给定用户的所有帖子。

使用iOS应用程序1.0版的人不会将任何数据写入'/ user-posts'，因为该端点并不存在。使用2.0版的用户因此看不到使用旧版应用的用户创建的任何帖子。

理论上我可以创建一个服务器来监听'/ post /'上的变化，并将它们添加到'/ user-posts'中。这似乎很难保持一段时间，虽然如果你有很多不同版本的应用程序。问题的

新特性实例：

让您的移动应用的1.0版本，说你写新博客文章“/职位/”。现在，在您的应用2.0版本中，您将引入一个团队功能，并且所有帖子都必须位于“/ team/team-id/posts”中。

尚未升级到2.0版的用户仍将写入'/ posts'。那些正在阅读'/ team/team-id/posts'的版本2.0的用户不会看到这些帖子。

我意识到你可以同时保留两个端点（以及基于团队ID的索引/帖子），但随着时间的推移，这似乎很难保持。

传统的解决方案：

如果我使用类似的Django或快递我会做一个数据库迁移，然后更新服务器端的端点创建的相关博客文章。

这将从客户端更改数据库。我可以在理论上一个应用服务器层添加到我的建筑与Firebase，但似乎并不像它的建议：https://firebase.googleblog.com/2013/03/where-does-firebase-fit-in-your-app.html

Answer 1

我会建议你使用Firebase Remote Config通过UIAlertController或不同的屏幕显示警报是否有更新可用。您可以强制用户更新到当前版本，以后再也没有问题，因为不能创建包含旧代码的帖子。

要回答你的问题： 我会制定了不同的应用程序，将其添加到同一个项目火力地堡，然后让这个应用中的所有旧数据转换为新的数据模型。因此，在发布新版本之后，您可以这样做一次，并且旧用户数据将转换为新数据模型，并且所有工作都可以顺利进行。对于每个对象，您还可以拥有像databaseVersion这样的属性。

为防止将来出现问题，您可以在您的Firebase Realtime Database中使用名为app-version的一般属性。在每次发布之前，应用程序会检查是否有更新的版本。如果不是用户可以添加帖子，但是如果有更新的版本，您可以通过UIAlertController