javascript - onupgradeneed事件中版本更改事务的正确代码结构

Question

我很难理解可以在onupgradeneeded事件中放置多少代码，以及如何确保在执行该操作之前，该代码中对数据库的所有单个异步更改都将始终完成。

如果我正确理解规范，则在打开数据库的请求中触发onupgradeneeded事件时，将自动创建模式为“ versionchange”的事务。

因此，在onupgradeneeded事件中编写的所有代码都被视为一个事务。我假设如果到达oncomplete，它将触发打开请求的onsuccess事件，如果到达onerror，则触发打开请求的onerror事件。

我对代码的复杂程度感到困惑。

例如，在事务中包含另一个异步事件（例如“ objectStore.transaction.oncomplete = function（event）{}”）以等待创建对象存储然后再尝试写入它是否安全？

还是应该在确定已创建打开请求的onsuccess事件中将数据写入到onupgradeneed事务中创建的对象存储中？

而且，正如MDN Web文档中一个较旧的示例中所发现的，onupgradeneeded事件内是否应该再有一个db.onerror事件？ https://developer.mozilla.org/en-US/docs/Web/API/IDBDatabase#setVersion()_.0A.0ADeprecated

另一个示例特定于我的数据库。该数据库具有一组投资组合，其中每个投资组合具有对象存储库（例如port_data_3）和可变数量的模块存储库（例如module_3.2），指示第三投资组合的第二个模块。此外，有一个port_key对象存储，每个投资组合保存一个记录，其中包含投资组合名称及其唯一键，在此示例中为3。

如果用户决定从数据库中删除投资组合3，则需要进行版本更改，其中包括三个主要步骤。 1）必须删除port_key存储中键3的单行； 2）必须删除port_data_3存储； 3）所有名称以“ module_3”开头的商店。必须删除。

诸如d = db.objectStoreNames，l = d.length之类的内容可用于遍历d.item（i）以确定应删除哪些存储。但是，在所有这些单个删除均已完成或失败之前，事务是否将始终保持打开状态？

同样，投资组合的添加/删除和投资组合中模块的添加/删除也需要版本更改。拥有一个开放功能以使所有这些版本更改类型的代码都处于一个更复杂的onupgradeneed事件中是否安全，还是为每个版本更改类型都具有单独的开放功能以使onupgradeneed事件代码更佳？每个都尽可能简单？

我想我的困惑的部分原因是由于一个事务是由许多独立的异步进程组成的，并且我不控制如何将它们分组为一个事务事件。我必须使用Promise或Promise.all或异步函数或生成器在其余的代码中执行类似的操作。而且让我的小脑筋感到难以置信的是，我不会错过任何迟发的错误。

我认为，如果将打开的请求包装在一个Promise中，并且将Promise放在try / catch中并等待，那会更安全。但这仍然没有改变onupgradeneed和它的versionchange事务如何确定所有这些异步过程是否成功或至少一个失败。

感谢您提供的任何指导和解释。

回应乔希的回答

感谢您的详细回答。它对我有很大帮助。

这也有助于我理解您在五月份时对我的一个问题（也许是我在此处提交的第一个问题）的回答，因为我当时当时并不太了解。问题是How to map mulit-level object to indexedDB for best efficiency。

鉴于您对这个问题的回答，我想现在知道了。我可以更改数据库结构，以使由于用户添加产品组合和模块而无需升级数据库。而且，正如您在对先前问题的回答中所建议的那样，所需的三个键（组合，模块和模块下的项）可以是三个索引，并且三个的组合也可以是索引，因为这将是查询最常需要的。实际上，除非我让浏览器生成一个标识符，否则这三个的组合是我唯一的唯一标识符。因此，代替可变数量的多个模块对象存储，而增加每个模块对象存储都需要数据库升级，将等效于一个模块对象存储，其中包含所有产品组合和所有模块中的先前数据对象。将多个投资组合级别的商店合并为一个，将执行相同的操作。

这简化了该数据库，并消除了我所关心的onupgradeneed的代码/事务的最大部分的需求。有了这些更改，我认为我终于可以重新更新程序，以使用indexedDB而不是localStorage，甚至可以重新开始睡觉。在这种情况下，编码本身不是具有挑战性的部分，而是确定有效的数据库结构。

也感谢您提供有关如何更好地安排未来问题的信息。

Answer 1

在需要升级的事件侦听器中，可以有一堆所谓的“异步”内容。从升级所需的处理程序中侦听versionchange事务的完成事件是安全的，尽管我会补充说这并不值得。
但是，在onupgradeneed内执行等待的fetch调用之类的操作并不安全。在运行时，事务将在调用解决之前完成，并且所有排队的操作都将失败。
一个事务可以有多个请求。
只要有待处理的请求，事务将保持打开状态。
事务通常将保持打开状态，直到事件循环的当前时间段结束为止，有时在此之后稍长一点。
事务在检测到没有待处理的请求后很短的时间内自动完成。
尝试在事务打开时将fetch之类的异步调用排队，然后等待提取完成，然后对该打开的事务进行插入，因为该事务将在此之前完成，因此将无法完成直到最早在事件循环的下一个纪元开始时才进行解析，但由于未检测到新请求，因此事务较早解析。
事务基本上是从一开始就设置为超时。每次发出请求时，您都会使它们的存活时间更长一点。
事务在其请求完成时解决/结算/完成。不只是在请求开始时。尚未完成的请求仍待处理。具有待处理请求的事务将无法完成（超时）。
一个请求可以成功完成或出错，都可以解决该请求。
具有多个挂起请求的事务（其中一个请求失败）可能会中止其他挂起的请求，并仅以错误结束。该一个请求错误将成为事务的错误。事务然后以该错误结束。


请注意在Mozilla开发人员网络（MDN）等地方发现的函数的一些谨慎的文档措辞。例如store.delete(thing)。 delete函数在与商店关联的事务中创建一个新请求。这是一件非常安全的异步操作。您可以像这样创建任意数量的其他请求。您不必等待事务完成即可添加新请求。您不必等待其他请求完成就可以开始新请求。您不必在开始事务之前等待事务完成（需要警告，需要onupgrade的特殊版本更改事务）。

事务只是一组请求。这是一个分组，可以帮助您说请求是一起生活的，并且一起消亡。如果任何一个请求失败，则整个组都会失败。这就是交易的重点。它非常有用，indexedDB不能为您提供其他方式发出请求，您甚至不得不为一个请求使用事务。如果您使用过SQL数据库，也许您遇到过START TRANSACTION; SELECT ...; END TRANSACTION;之类的语法。这里也是一样。除了indexedDB不允许您在事务之外执行SELECT ...（您可以在SQL中完成）。另外，indexedDB不允许您自己明确结束事务。您只需决定不创建更多请求并允许其不久后超时就可以完成indexedDB事务。

关于您的总体编程设计，我强烈建议您选择一种设计，在这种设计中，您无需随着数据的更改以及应用程序/世界中发生的事情而更改数据库架构。通常，模式应该是恒定的。如果您发现自己通常需要经常创建和删除对象存储，这是应用程序的正常操作，那么我会认真考虑一下设计。

同样，虽然您可以从onupgrade所需的数据中插入数据，但通常应该从IDBOpenRequest的成功事件处理程序中进行数据插入。这是一种常规规则（不是正式的规则），即对数据的更改必须成功，而对模式的更改需要进行onupgrade。如果您在网上遇到一些需要在升级时进行数据更改的示例，我建议您仔细阅读，在这些示例中，这样做通常会很快且出于便利目的，而不是适当的应用程序设计。

顺便说一句，如果您将这个非常广泛的问题分解为一些小片段，以突出您的困惑区域，并显示示例代码出乎意料的效果，或者在其中添加注释以突出显示您不知道如何处理的部分，您将获得更好的答案。制定。