{"id":40703,"date":"2023-10-02T09:42:58","date_gmt":"2023-10-02T13:42:58","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=40703"},"modified":"2023-10-11T16:43:41","modified_gmt":"2023-10-11T20:43:41","slug":"model-for-coredata","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2023\/10\/02\/model-for-coredata\/","title":{"rendered":"@Model for CoreData"},"content":{"rendered":"

Helge Heß<\/a>:<\/p>\n

ManagedModels<\/a> is a package\nthat provides a\nSwift 5.9<\/a> \nmacro similar to the\nSwiftData\n@Model<\/a>.\nIt can generate CoreData\nManagedObjectModel<\/a>’s\ndeclaratively from Swift classes, \nw\/o having to use the Xcode “CoreData Modeler”.<\/p>

Unlike SwiftData it doesn’t require iOS 17+ and works directly w\/\nCoreData<\/a>.\nIt is not<\/strong> a direct API replacement, but a look-a-like.<\/p>

[…]<\/p>

A CoreData object has to be initialized through some \nvery specific initializer<\/a>,\nwhile a SwiftData model class must have<\/em> an explicit init<\/code>, \nbut is otherwise pretty regular.<\/p>

The ManagedModels @Model<\/code> macro generates a set of helper inits to deal with\nthat.\nBut the general recommendation is to use a convenience init<\/code> like so[…]<\/p><\/blockquote>\n

I like this general approach, but my experience is that it’s not good to cache the NSEntityDescription<\/code>. If you return it from a class method, there can be problems if you use the same managed object class with multiple managed object models or multiple instances of the same model when testing. (I avoid the similar convenience methods that are built into Core Data, too.) Maybe this has since been fixed, but I found that it worked better to specify the entity by name in the fetch request so that it gets looked up in the proper managed object model.<\/p>\n\n

Previously:<\/p>\n