android - 房间数据库迁移

Question

如果我有 db version 10，我必须为 Room 迁移做多少种方法？

我查看了以下示例 Google Persistence Migration Sample

并且我根据数据库版本 4 的可能场景找到了迁移可变参数。

public static UsersDatabase getInstance(Context context) {
    synchronized (sLock) {
        if (INSTANCE == null) {
            INSTANCE = Room.databaseBuilder(context.getApplicationContext(),
                    UsersDatabase.class, "Sample.db") 
                    .addMigrations(MIGRATION_1_2, MIGRATION_2_3, MIGRATION_3_4, MIGRATION_1_4)
                    .build(); 
        } 
        return INSTANCE;
    } 
} 

我的问题是，假设我从 db v1 使用 Room，当我的应用程序达到 db v10 时，我必须编写多少迁移方法？

在 sqlite 中，我们在 onUpgrade 中获取已安装应用程序的当前数据库版本，我们只是在没有 break 语句的情况下通过 switch case 来满足所有数据库升级。

但是，我不确定，但据我所知，我们无法在房间中获取已安装应用程序的当前数据库版本，我们编写了所有可能的迁移方法。

但是如果我有db v10，感觉好不方便，一共写45个方法不合适!

有没有更好的解决方案？

Answer 1

Suppose I am using Room from the db v1 and by time my app reaches to db v10, how many migration methods will I have to write?

9.

一种方法是:1->2、2->3、3->4、4->5、5->6、6->7、7->8、8->9 和 9->10.

另一种方法是:1->10, 2->10, 3->10, ..., 9->10。

我的猜测是第一种方法更受欢迎，因为它更容易开发。对于每个新的数据库版本，您只需创建一个额外的对象。

In sqlite, we get current db version of installed app in onUpgrade and we just fall through switch case without break statements so that it satisfies all db upgrades.

这将与您在 Room 中所做的代码行数大致相同。您的每个 case 语句都会变成一个 Migration 对象，处理增量升级(例如，3->4)。

But it feels so inconvenient, inappropriate to write total 45 methods if I have db v10!

Room 知道如何根据需要“拼接”各个迁移以达到目标版本。因此，在我概述的第一种方法中，如果应用需要从 3 迁移到 10，Room 可以使用 3->4、4->5、5->6、...、9->10 来获取那里。