change PrimaryKey attribute - handle with ObjectID about synckit

[spotlessicode]

and one more statement could be useful: if updatedID2s entity is nil, then the object should be inserted instead of being updated.

[mentrena]

If primaryKey attribute changes

Primary keys are not expected to change. If you need to change its value for some object, then that's an indication that the field shouldn't be used as the primary key field. Instead, add another field to your object and assign a unique value to it.
If you use an API your objects probably already get a unique value. Otherwise you might want to use [[NSUUID UUID] UUIDString];
The documentation should probably be more explicit about this, I will update it.

Regarding use of NSManagedObjectID: we can't rely on it because it will change as a result of a model update, so it's not reliable when it comes to tracking objects. SyncKit originally used NSManagedObjectID but when this limitation became apparent the primaryKey solution was added. I would actually like to completely drop the old behaviour and force users to provide a primaryKey field for their classes, it would avoid several problems.

[spotlessicode]

the problem is with this, that you can add a primaryKey for the object, but that will be just an identifier, as ObjectID, and doesn't avoid duplications in CloudKit with the Name attribute if the user creates them on different devices... that was what primaryKey as a unique identifier meant to me. but ok, I'll try to handle it locally.

[mentrena]

Assigning a NSUUID as your identifier when you create objects would fix that issue --it's what I do in my own app

[spotlessicode]

Thanks, I’ll. ;)

…

On 2017. Aug 17., at 10:11, Manuel Entrena ***@***.***> wrote: Assigning a NSUUID as your identifier when you create objects would fix that issue --it's what I do in my own app — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJOdbAR1wU2rPb_rHDCsYgSjWzP7oGpYks5sY_WhgaJpZM4O4wd9>.

[spotlessicode]

I made modifications and test with it. my final opinion: The NSUUID just an identifier, and unfortunately, it can happen, that objects creates and upload to CloudKit with the same attribute (in my case it's important with one Name attribute just one object can exist, what I can manage, when the user create them, but I can't if there was a chaos with this nil primaryKey values at objects.. finally, of course, I can that too with a final deduplication check - but for those, who had same Problem - must to check the relationship at that objects too, and delete the good one!).

With proper scanning, synchronize database before creating new objects can be duplication avoided. However, if the user's iCloud account and/or Drive is unavailable or the user is not online and does not have the latest database, such problems may occur... and I don't think so that a good idea to handle it just with an easy deletion, rather than ask the user what should do. But in some situation, the user can't decide it, because the user can't see, which one of the same name objects has which relationships with other objects.. this issue needs some workaround.

[mentrena]

I get how it's an inconvenience for your use case, but I think de-duplication might be the only solution in this case.

One suggestion would be to check the importContext for goals with the same name in changeManager:didImportChanges:completion:, then use the modified field to work out which one to keep. That way you ensure that de-duplication happens in the child context, before the main context gets updated.

[spotlessicode]

Thank you, yes this could be the best way!

…

On 2017. Aug 17., at 23:09, Manuel Entrena ***@***.***> wrote: I get how it's an inconvenience for your use case, but I think de-duplication might be the only solution in this case. One suggestion would be to check the importContext for goals with the same name in changeManager:didImportChanges:completion:, then use the modified field to work out which one to keep. That way you ensure that de-duplication happens in the child context, before the main context gets updated.