服务器记录中的CKAsset不包含fileURL，甚至无法检查nil [英] CKAsset in server record contains no fileURL, cannot even check for nil

问题描述

当我使用CKModifyRecordsOperation和.IfServerRecordUnchanged的保存策略来保存包含CKAsset(仅是JPG图像)的记录时，我正在测试同步冲突.我收到错误CKErrorCode.ServerRecordChanged.此CKError向我返回了有关解决冲突的有用信息，包括我尝试保存的CKRecord以及记录的当前服务器版本.第一个在error.userInfo[CKRecordChangedErrorClientRecordKey]中，第二个在error.userInfo[CKRecordChangedErrorServerRecordKey]中.

I am testing a sync conflict when I save a record that contains a CKAsset (simply a JPG image) using CKModifyRecordsOperation with a save policy of .IfServerRecordUnchanged. I am getting the error CKErrorCode.ServerRecordChanged. This CKError returns me useful information for conflict resolution, including the CKRecord I tried to save, and the current server version of the record. The first is in error.userInfo[CKRecordChangedErrorClientRecordKey] the second is in error.userInfo[CKRecordChangedErrorServerRecordKey].

我的问题是我正在尝试使用以下代码访问服务器记录的CKAset:

My problem is I am trying to access the server record's CKAsset with this code:

if let photoAsset = rec["myPhoto"] as? CKAsset {
  print("PhotoAsset.fileURL: \(photoAsset.fileURL)")  // BAD_ACCESS ERROR HERE
  self.myPartner.photo = NSData(contentsOfURL: photoAsset.fileURL)
}

我不知道这怎么可能.但是，在进一步调查之后，我打印出了客户端和服务器CKRecords，而服务器一缺少了"path"属性.

I don't get how this is possible. But after further investigating, I print out the client and server CKRecords and the server one is missing the 'path' property.

客户端CKAsset ... myPhoto(已修改)-> CKAsset:0x7b960d90;路径=〜/tmp/BF185B2C-7A39-4730-9530-9797E843243A照片，大小= 373959，uploadRank = 0，uploadReceipt = A92Eg1qoyPG7yrg3，UUID = 3C2D5DC8-4FF5-4A81-853B-395FC1C59862，referenceSignature =< 012fd149200e3ee 600e3e3e6e3e6e3e3e6e3e3e6e6e3e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e3c3c3c3c3c3c3c7bfbfc3c3c3c3c3c7b3c人>，标志=已上传，已包装EncryptionKey =，签名= <0134a297 38d52f5f 9275bfba fce5b1a8 3d6b9692 d3>

client CKAsset...myPhoto (modified) -> CKAsset: 0x7b960d90; path=~/tmp/BF185B2C-7A39-4730-9530-9797E843243Aphoto, size=373959, uploadRank=0, uploadReceipt=A92Eg1qoyPG7yrg3, UUID=3C2D5DC8-4FF5-4A81-853B-395FC1C59862, referenceSignature=<012fd149 200fc600 617e3907 88763e3e 5002abbf 5b>, flags=uploaded, wrappedEncryptionKey=, signature=<0134a297 38d52f5f 9275bfba fce5b1a8 3d6b9692 d3>

服务器CKAsset ... myPhoto = CKAsset:0x7be700d0; referenceSignature =< 015337bd 84409893 7c014f46 36248d27 ce911dc3 7a>，size = 373959，uploadRank = 0，UUID = DF5D2EB4-033C-49A2-AF52-6055B5A44106，wrappedEncryptionKey =< 767e7cfd d1e62110 32119ee9 5a6e0b = 0de6a3d3d3b6a0f6f026b 9275bfba fce5b1a8 3d6b9692 d3>

server CKAsset...myPhoto = CKAsset: 0x7be700d0; referenceSignature=<015337bd 84409893 7c014f46 36248d27 ce911dc3 7a>, size=373959, uploadRank=0, UUID=DF5D2EB4-033C-49A2-AF52-6055B5A44106, wrappedEncryptionKey=<767e7cfd d1e62110 32119ee9 f6f026b3 5bcf0cc3 8053a4de>, signature=<0134a297 38d52f5f 9275bfba fce5b1a8 3d6b9692 d3>

请注意，服务器一缺少path=~/tmp/C706423B-A3E8-4051-A9B3-483C718BFBF5photo吗?谁能解释一下?要解决此问题，我尝试避免从服务器记录中触摸CKAset.我至少希望能够检查nil.我想把它放在那里，以防它对其他人有帮助.

Notice how path=~/tmp/C706423B-A3E8-4051-A9B3-483C718BFBF5photo is missing from the server one? Can anyone explain this? To fix it I try to avoid touching the CKAsset from the server record. I would like to at least be able to check for nil. I wanted to put this out there in case it helps anyone else.

推荐答案

这似乎是正确的行为，而不是错误.

This seems like the correct behavior, not a bug.

CloudKit通知您您的 write 操作失败，因为您未使用最新的CKRecord进行操作，并为您提供了服务器当前CKRecord的非水合版本，因此您可以确定哪些字段与您的起点.其余的取决于您.

CloudKit informed you that your write operation failed because you weren't working from the latest CKRecord and gave you a non-hydrated version of the server's current CKRecord so you could determine which fields were different from your starting point. The rest is up to you.

如果CloudKit在错误响应中返回了完全水合的服务器记录以进行写操作，则可能会浪费大量带宽/资源.

If CloudKit returned the fully hydrated server record in the error response for a write operation, it would potentially waste enormous amounts of bandwidth/resources.

这就是为什么存在CKAsets的原因:将与CKRecord关联的受大小限制的键值字段与可以附加到它们的无限制大小的二进制资产分开.

That is why CKAssets exist: to separate the size-constrained key-value fields associated with a CKRecord from the unlimited-size binary assets that can be attached to them.

这篇关于服务器记录中的CKAsset不包含fileURL，甚至无法检查nil的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！