As I'm beginning with CloudKit I've looked at several people's example code. I've followed the patterns there - but sometimes following an example without truly understanding the reasons and methods underlying the code can lead to problems. I feel I've discovered one of these problems - yesterday.

I've been using the article of Majid's Fasting Example. In this example he uses a converter computed property to construct the CKRecord. So of course I did the same. I'm not saying his code is bad/wrong or anything like that... it has helped me alot. I'm saying I followed it blindly and incorrectly - my mistake.

Here's my code... spot the mistake?

I create a CKRecord on init() for the WLTicker object. But I never do much with that local ckRecord (a property of the WLTicker). Then later when I want to CKPrecipitable (my cute name) for a protocol that marks the class as being able to be read/writen to iCloud - Precipitation - meaning: rain, or snow from the clouds. I use my convertToRecord
computed property, which creates yet another CKRecord - Opps!

So then when I write the CKRecord to the Cloud DB and read it back out my code is confused by which record I want to delete when I've asked the App to delete a Ticker.

I think I've found my error... Now which pattern is the better example to follow?

Should I keep using the converterToRecord property? Or should I keep the CKRecord as a property of the WLTicker? Or is there some other pattern that I should consider? Hmm.

The realization I've had today is the CKRecord is a key-value (Dictionary) with some unique metadata. It is designed to wrap the typical primitive values - NOT be wrapped! So having the CKRecord held by my WLTicker object is a poor practice. It is going to cause some recursion/redundant something when I call the convertToRecord.

I'm now thinking (and this could change as I learn better practices) that I should work with the system... allow the CKRecord to wrap my WLTicker (WL = Watch List).

Let's see what happens when I rewrite the persistence code to work with CloudKit.

I think this is going to matter a lot more as the simple example code becomes more complex with CKRecord.Reference objects. When I tie my WLTicker to the Transactions I'm about to create. Do you know which one should have the reference? I'm guessing! I'm going to start with a Transaction holding a reference to a WLTicker.

Do you have any ideas - let me know on Mastodon.