Core data turning objects into faults inappropriately

Question

Created Aug ’24

Replies 4

Boosts 0

Participants 2

It seems that when an entity has and ordered to-many relationship to the same entity, inserting an object into the ordered set causes other objects of the set to turn into faults during the next save of the managed object context.

I verified it with several applications. For the sake of example, the entity will be called Folder and the ordered to-many relationship subfolders (an NSOrdereset), with a cascade delete rule. The reciprocal to-one relationship is called parent.

Assuming you have a Folder object with two subfolders, removing the last subfolder from the set (setting its parent to nil) and reinserting it at index 0 with insertObject:<>inSubfoldersAtIndex:0 will turn the other subfolder into a fault at the next save.

Now assuming that other folder has a name attribute (NSString) that is bound to a textfield in your UI, the name of that subfolder will disappear when the context saves, since it becomes nil while the subfolder is turned into a fault.

Is this expected behavior?

Note: I'm using Objective C, Xcode 15 and macOS sonoma, but I've seen this issue occur on previous macOS versions.

Boost

Answer 1

jeanlain OP

Aug ’24

Of note, objects that turn into faults are those that has no pending changes, that is, those that were not inserted nor removed in/from the ordered collection. I can avoid the issue by making dummy changes to these objects, such that they don't turn into faults during the next save, but I'd like to understand the root cause.

Maybe I don't know how to manage ordered collections properly. To insert an object, I use insertObject:inSubfoldersAtIndex and I don't modify other objects of the collection. Should I reorder all objects? The documentation says little about ordered to-many relationships.

0

Answer 2

jeanlain OP

Aug ’24

Update: the to-many ordered relationship doesn't have to point to the same entity for this issue to occur (in my example, the "parent" and "subfolders" can be different entities).

0

Answer 3

DTS Engineer OP

Apple

Aug ’24

inserting an object into the ordered set causes other objects of the set to turn into faults during the next save of the managed object context.

This doesn't sound right, but the framework may fault an object for other reasons. Specifically, when you use a nested managed object context, the framework may fault an object more aggressively.

Now assuming that other folder has a name attribute (NSString) that is bound to a textfield in your UI, the name of that subfolder will disappear when the context saves, since it becomes nil while the subfolder is turned into a fault.

This isn't the right behavior – Even the object is faulted, when you access its attribute, Core Data should bring the object back and make the value available to you.

The reason of the described issue isn't obvious to me though. You might provide a minimal project that contains only the code relevant to the issue, with detailed steps to reproduce the issue, for folks to take a look, if you need more assistance.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

0

Answer 4

jeanlain OP

Aug ’24

Hi Chen. I too wonder why the binding does not bring back the object's attributes. Here a link to a simple project. https://upoitiers86-my.sharepoint.com/:u:/g/personal/jean_peccoud_univ-poitiers_fr/Eap9s3nnTfZGod0dfcDzhZ4BS6KVlJ-XCChuzsEhQyjpwA?e=YmSvqb

To reproduce the issue, just click the "Swap folders" buttons, which reorders two Folder objects in an ordered to-many relationships, then saves the context (see swapFolderPositions: in AppDelegate.m).

The name attributes of the folders are bound to two text fields, and you will see a name disappear when a folder is turned into a fault (a message is logged in the console when that happens, since I override willTurnIntoFault.

0