我们面临着一个问题。
当我们试图打开 IndexedDB 时，没有回调被触发。
我们正在执行以下步骤：
1.open 数据库，使用以下步骤：
request = indexedDB.open(name, 10);
request.onerror = onError;
request.onsuccess = onSuccess;
request.onupgradeneeded = onUpgradeNeeded;
request.onblocked=onBlocked;<br>2.注意没有回调被触发。
3.open chrome：//indexeddb-internals/#，它显示先前删除的数据库正在挂起。
2条答案
按热度按时间gcmastyq1#
您可能打开了另一个与数据库连接的选项卡。
打开/删除请求进入队列。未指定版本的打开请求（或指定与目前数据库相同版本的）可以在到达队列前端时立即行程。到达队列前端的开启更高版本要求或删除要求必须等到所有其他联机关闭。如果它们在收到“versionchange”时立即关闭则请求继续进行。如果不是，则请求得到“阻塞”事件并等待直到连接关闭。
请注意，队列中的其他请求不会获得事件-它们只是等待，直到到达队列的前端，然后被处理或“阻塞”
在步骤3中，您报告有一个先前的删除请求挂起，这表明它在某个地方被阻止了;可能还有另一个连接在附近，所以delete请求在队列的前面并被“阻塞”，而你的open请求（对于版本10）在队列中位于它的后面，并且（正如你所注意到的）它在到达队列的前面之前不会看到事件。
63lcw9qa2#
虽然约书亚Bell的答案是正确的，但我想添加（基于他的答案：）blocked = upgradeBlocked（只有当您有保持连接打开策略，并且您的应用在多个选项卡中打开，并且您尝试在一个选项卡中升级架构，但另一个选项卡中的其他打开连接在触发versionchange事件时没有关闭，因此升级被阻止），您的代码似乎是queueBlocked，但您没有侦听器。
我自己实现了一个请求超时，这样我就可以知道超时，成功，升级和成功，或者错误在超时提供的时间范围内触发。我假设阻塞不会发生，因为我总是在版本更改时关闭连接。
当然，我想好的代码通常不会遇到超时。所以这是为了完美的运行时处理。如果你经常遇到超时，那么问题的根源就在其他地方。所以有onBlockedUpgrade和onBlockedQueue并没有真正的帮助。有像xhr这样的内置超时将是很好的：）
但是很高兴从约书亚Bell那里知道了这个“队列的事情”：）你最好实现超时，在这个具体的例子中，你应该在其他地方找到问题。