Core Data Plus CloudKit - Potential Issue / Question about Binary Data w/ External Storage

Question

Created Apr ’23

Replies 4

Boosts 1

Views 1.4k

Participants 2

I added Core Data to my app. My core data model has an Entity with 3 Binary Data attributes with external storage along with other attributes. I saved an array of data to core data and when I examine the result on CloudKit Dashboard, I see two of the three data record fields are of type Bytes and one is of type CKAsset. Looking at a particular piece of data in the cloud (I added Queryable to recordName), I see the CKAsset data as 'Binary File (645.17KB)' and the Bytes data as '77+9UE5HDQ (660.66KB)'. Will this pose a problem? Why isn't the data all CKAssets in CloudKit? Will the Bytes record field hold enough data? Searching the web, I've see others having problems with Binary Data and Core Data Plus CloudKit in the past, but nobody has mentioned this specific result.

Answered by DelawareMathGuy in 751342022

hi SpaceMan,

the best reference i can find on this is in the developer documentation on Reading CloudKit records for Core Data. this documents how Core Data is encoded in CloudKit.

in short, String, Binary Data, and Transformable attributes can be automatically converted to external assets during serialization. it looks like this happens when you begin approaching 1 MB, but there seems to be no hard-and-fast rule.

however, you can certainly work with the CKRecords directly and determine whether data is in the record or farmed out to a CKAsset, as described in the article above: "When inspecting a CloudKit record directly, check the length of the original field’s value; if it is zero, look in the asset field."

hope that helps,

DMG

Boost

Answer 1

SpaceMan OP

Apr ’23

I'm running the app in the Development environment and have not committed the CloudKit Schema to the Production environment.

0

Answer 2

SpaceMan OP

Apr ’23

I know it's great for those new to Core Data and CloudKit for the system to automatically create record fields in CloudKit, but in this case, I wish I had control over the result to define this piece of binary data as a CKAsset in CloudKit. I will never manipulate the CloudKit data directly, but it would be nice to have consistency in the linking of Core Data binary data to CloudKit fields.

0

Answer 3

DelawareMathGuy OP

Apr ’23

hi,

as long as you're OK with "I will never manipulate the CloudKit data directly," then i don't see what the problem is. i doubt that the NSPersistentCloudKitContainer designers ever intended for users to be interacting directly in code with CKRecords and making an end run around what NSPersistentCloudKitContainer does for you automatically.

however, that aside, i do recall reading at one point that Core Data does not necessarily use external storage just because you checked "Allows External Storage." it could be the case that Core Data made such decisions about your data at some point; if so, the CloudKit representation of what NSPersistentCloudKitContainer does for you would probably respect that decision.

hope that helps,

DMG

0

Answer 4

DelawareMathGuy OP

Apr ’23

Accepted Answer

hi SpaceMan,

the best reference i can find on this is in the developer documentation on Reading CloudKit records for Core Data. this documents how Core Data is encoded in CloudKit.

in short, String, Binary Data, and Transformable attributes can be automatically converted to external assets during serialization. it looks like this happens when you begin approaching 1 MB, but there seems to be no hard-and-fast rule.

however, you can certainly work with the CKRecords directly and determine whether data is in the record or farmed out to a CKAsset, as described in the article above: "When inspecting a CloudKit record directly, check the length of the original field’s value; if it is zero, look in the asset field."

hope that helps,

DMG

0