indexedDB:“_proto_”在数据库对象中做什么?

indexedDB: What is "_proto_" doing in the database objects?

对象在 indexedDB 中的存储方式是否发生了变化,至少在 Firefox 中是这样?

我现在注意到在开发人员工具存储选项卡中出现了“_proto_”。直到我在我的程序中观察到我无法弄清楚的奇怪行为之前,我并没有多想。

我认为对象在写入数据库之前被克隆,因此无论它们是如何创建的,它们都是独立的。例如,在第一次创建数据库时,添加了一些映射对象;并且,由于多个对象具有完全相同的 layout/structure,因此重复使用了对单个对象的引用,如下所示。

加载页面时,映射数据被读入 RAM 并用于管理数据库键的分配。除非我真的很困惑,否则 prop_3 到 prop_7 似乎在稍后重新加载页面时从数据库中提取时保留了公共引用,这样如果 prop_3 中的属性之一是已更新,相同的 属性 在 prop_3 到 prop_7 中更新。

这是它应该的工作方式吗?我预计 prop_3 到 prop_7 在从数据库写入和读取后不再共享公共引用。

如果这是准确的,对象可以以不保留这些类型的共享引用的方式写入数据库吗?当然,我意识到可以不使用对 repeated_object 的引用来对它们进行不同的分配;事实上,这为我解决了具体问题。谢谢。

repeated_object = { ...property : value... };
os.add( { 'prop_1' : 1, 
          'prop_2' : 2,
          'prop_3' : repeated_object, 
          'prop_4' : repeated_object,
          'prop_5' : repeated_object,
          'prop_6' : repeated_object,
          'prop_7' : repeated_object  } );

How is a reference to an object that was not written to the database serialized? When that example object is retrieved from the database those last five properties are still treated as references to the same single object.

是的,这是预期的。 IndexedDB does not use something like JSON.stringify(value) that would serialise an object multiple times if it was referenced multiple times. Instead, it uses structured cloning,不仅支持序列化更多类型,还支持循环引用或共享引用

Is that new to Firefox?

不,这应该在所有浏览器中保持一致。

and is it done through _proto_?

不,一点也不。这与它无关。结构化序列化不保留原型对象(内置对象除外)。