我有一个具有高基数合成分区键和类型属性的cosmos db。 我需要一个设置,使用户可以在它们之间共享文档。
例如,这是一个文档:
{
“id”:”guid”,
“title”:”Example document to share”,
“ownerUserId”:”user1Guid”,
“type”: “usersDocument”,
“partitionKey”:”user_user1Guid_documents”
}
现在,用户希望与其他用户共享此文档。
假设:
由于以下两个原因:
document
文档或user
文档中(因为写入很快就会变得无效/昂贵),但是我更希望将这些m:n
是单独的文档。< / li>
我需要两个查询:
1。 ListDocumentsSharedWithMe
在此查询中,在查询时,我知道id
文档中的user
是共享的。
2。 ListAllUsersISharedThisDocumentWith
在此查询中,在查询时,我知道‘id of the
文档that has been shared with different
用户`。
所有这些使我认为我应该具有2个具有独立分区的独立文档类型
列出与我共享的所有文档:
{
“id”:”documentGuid”,
“type”:”sharedWithMe”,
“partitionKey”:”sharedWithMe_myUserGuid”
}
(这也可以是包含共享文档集合的单个文档。重要的是partitionKey)
现在,我可以轻松地执行类似SELECT * FROM c WHERE c.type = “sharedWithMe”
的SQL并针对包含我的用户guid的分区键运行查询。
要列出与我共享某个文档的所有用户,类似:
{
“id”:”userISharedWithGuid”,
“type”:”documentSharings”,
“partitionKey”:”documentShare_documentGuid”
}
现在,我可以轻松地执行类似SELECT * FROM c WHERE c.type = “documentSharings”
的SQL并针对包含我的文档guid的分区键运行查询。
问题:
当用户与某个用户共享文档时,应该使用不同的分区键(因此,没有sp /事务)创建两个文档。
如何保持这种“原子状”或避免创建/更新异常?
还是有更好的方法对此建模?
答案 0 :(得分:1)
我认为您的方法有意义,我可以根据查询的范围以多种方式执行类似于分区的操作。我认为您主要担心的是在保存第一组和最后一组相关文档之间是否发生故障?不幸的是,保存文档链的唯一方法是在应用程序代码中。也就是说,我们确保以最容易回滚的顺序进行保存,然后在异常处理程序中实现回滚方法,这是通过将集合保存的文档保留在内存中来实现的。
正如您所说的那样,当您跨分区时,没有开箱即用的事务处理。