我想使用Google Drive实时API为有序项目的有序嵌套列表建模(就像您在标准树窗口小部件中看到的那样)。这些树木可能变得非常大,理想情况下可以很好地与数千种物品配合使用。
一种方法是:
Item:
title: CollaborativeString
attributes: CollaborativeMap
children: CollaborativeList // recursivly hold other items
但我不确定在处理大量物品时这是否可以免费。
另一种方法可能是将所有项目树顺序存储在单个CollaborativeList中,并添加一个额外的"级别"属性。然后在客户端上基于该级别重构树结构。这将从必须维护数千个CollaborativeLists变为仅仅一个大的。可能还有很多我不了解的其他选择。
感谢您提供有关在Google云端硬盘实时API中对此进行建模的最佳方式的建议。
答案 0 :(得分:1)
只要文档的总大小在size limits之内,从框架角度来看,这些方法之间不应存在显着的性能差异。 (有一点需要注意,使用具有高度连接图的ObjectChangedListeners可能会减慢速度。更喜欢在特定对象上注册侦听器。)
将其建模为真实的树是有道理的,因为这将是最容易使用的,并且您可以使用新的移动操作以原子方式重新排列列表中的项目。