为什么indexedDB使用“版本”？

我刚刚学习了indexedDB，这是我对建立数据库的理解。您可以拨打.open(dbName)来获取数据库实例。如果在用户的计算机上没有该名称的数据库（例如，这是他们第一次访问该站点），那么这会触发一个onUpdateNeeded事件，因此您应该在其中执行初始化操作，比如创建ObjectStores。为什么indexedDB使用“版本”？

现在，您还可以传递一个版本 - .open(dbName, version) - 并且如果数据库存在但使用较低版本，则无论如何这会强制执行onUpdateNeeded事件。现在，我可以看到这个实用程序......但为什么要有一个整数参数？如果“版本”参数的要点是强制更新，为什么不只是有一个forceUpdate标志？为什么需要一个整数版本参数，因此在调试代码时需要增加更高的版本，经过多天的调试后可能达到版本156？

除了强制更新之外，我还没有意识到某些功能是否使用了该版本，如果不是，那么它背后的基本原理是什么？此外，您是否打算在开发过程中不断更改版本，但在应用程序发布后保持固定，还是应该在应用程序的整个生命周期中不断更改它？

来源

2015-12-15 Jack M

* *之后它很有用：发布程序，某人使用它，保存了一些数据，并且创建了一个不兼容的数据存储更新。当然，对于本地测试，您只需要每次清除它。 – transistor09

的单调递增的整数允许此图案：

var open = indexedDB.open('db', 3); 
open.onupgradeneeded = function(e) { 
    var db = open.result; 
    if (e.oldVersion < 1) { 
    // create v1 schema 
    } 
    if (e.oldVersion < 2) { 
    // upgrade v1 to v2 schema 
    } 
    if (e.oldVersion < 3) { 
    // upgrade v2 to v3 schema 
    } 
    // ... 
}; 
open.onsuccess = function() { 
    var db = open.result; 
    // ... 
};

这是一个很常见的模式。显然，人们可以想象这是手动完成的 - 开发人员可以在特殊的元数据表中跟踪版本 - 而不是将其写入标准中。但它的内置是很常见的，类似于索引和密钥生成器。

有一个有效的论点认为，这使得API对于初学者来说太复杂了，但是没有时间机器，它有点没有实际意义。

...

如果你在本地调试和变化被限制到你的机器，然后删除/重新创建数据库可能比写模式升级的逻辑为每个小细节更容易。

来源

2015-12-17 00:59:43

我在这里有个人后续问题：实际上是否需要从每个可能的先前模式状态迁移新版本的每个条件块？如果您将注释升级v2升级到v3，您是否也必须始终考虑在同一个块中从v1升级到v3？例如。一个包含数据库模式的chrome扩展升级，它在更新之间经历了多个本地修订版本？ – Josh

哎呀，我在我的例子中犯了一个错误。它应该检查事件的oldVersion，而不是数据库的版本。修复未来... –

好的，修复 - 对此感到抱歉。由于if语句不包含else，因此必要时将运行多个块。 –

为什么indexedDB使用“版本”？

回答

相关问题