{"id":21492,"date":"2018-05-10T16:52:11","date_gmt":"2018-05-10T20:52:11","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=21492"},"modified":"2018-05-15T15:20:13","modified_gmt":"2018-05-15T19:20:13","slug":"the-laws-of-core-data","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2018\/05\/10\/the-laws-of-core-data\/","title":{"rendered":"The Laws of Core Data"},"content":{"rendered":"

Dave DeLong<\/a> (tweet<\/a>):<\/p>\n

In my conversations with developers, I’ve heard a pretty common theme from them that “Core Data is hard” or “Core Data is buggy” or “I could never get it to work right and gave up on it”.<\/p>\n

I’ve spent a lot of time using Core Data and thought I’d share my “Laws of Core Data”. These are a set of rules I’ve developed over time on how to use Core Data in such a way that it is almost entirely<\/em> painless. When I follow these rules, I almost never<\/em> have any problems using it.<\/p><\/blockquote>\n\n

Of particular note is that, contra<\/a> Zarra<\/a>, he thinks child contexts are usually unnecessary.<\/p>\n\n

Colin Cornaby<\/a>:<\/p>\n

I find that when most people complain that CoreData is not thread safe out of the box, they’re really saying “I’m able to ignore that my existing model code is also not thread safe.”<\/p><\/blockquote>\n\n

Core Data has its issues—for example, there is a lot to learn, it is verbose, there<\/a> are<\/a> some<\/a> persistent<\/a> bugs<\/a>, and in some cases it’s much slower than using SQLite directly—but overall I think it’s unfairly maligned<\/a>.<\/p>\n\n

Update (2018-05-11): Marcus Zarra<\/a>:<\/p>\n

\n

All of the internal workings of your Core Data stack, your persistence and data model absolutely should be stored in the persistent container and that container should be injected through your controllers in your application.<\/p>\n

[…]<\/p>\n

An NSManagedObject<\/code> is<\/strong> an NSObject<\/code> that has additional functionality added. It should absolutely be treated as if it is an NSObject<\/code> because it is an NSObject<\/code>. NSManagedObject<\/code> instances are your data objects and should be treated as such. Creating Plain Old Objects on top of NSManagedObject<\/code> instances is asking for pain and data corruption.<\/p>\n<\/blockquote>\n

The crux of the issue is that NSManagedObject<\/code> is an NSObject<\/code> that doesn’t obey that class’s standard contract. So it should not be treated as such. That said, I’m not sure there would be anything to gain by actually making it a separate root class. Creating plain objects on top of NSManagedObject<\/code> instances can be a useful pattern. It has really simplified some of my code and made it faster and more robust. But I would only do this on a case-by-case basis, not as a regular part of using Core Data.<\/p>\n

\n

If your app talks to anything<\/em> else then you will want to use parent-child contexts.<\/p>\n

The parent context should be on the user interface thread (the main thread) and when you need to do asynchronous work with your data objects (importing or exporting) then you want to do that on another thread and that work should be done in a child context.<\/p>\n

A child context simplifies the transfer of notifications of data changes and greatly simplifies using Core Data in a multi-threaded environment.<\/p>\n<\/blockquote>\n\n

See also: Colin Cornaby and Marcel Weiher<\/a>.<\/p>\n\n

Update (2018-05-15): See also: Peter Steinberger<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"

Dave DeLong (tweet): In my conversations with developers, I’ve heard a pretty common theme from them that “Core Data is hard” or “Core Data is buggy” or “I could never get it to work right and gave up on it”. I’ve spent a lot of time using Core Data and thought I’d share my “Laws […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"2018-05-15T19:20:16Z","apple_news_api_id":"ae9a3634-16dc-4814-a510-38207457e2aa","apple_news_api_modified_at":"2018-05-15T19:20:18Z","apple_news_api_revision":"AAAAAAAAAAAAAAAAAAAAAg==","apple_news_api_share_url":"https:\/\/apple.news\/Arpo2NBbcSBSlEDggdFfiqg","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[4],"tags":[800,109,31,1472,30,1529,71],"class_list":["post-21492","post","type-post","status-publish","format-standard","hentry","category-programming-category","tag-concurrency","tag-coredata","tag-ios","tag-ios-11","tag-mac","tag-macos-10-13","tag-programming"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/21492","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=21492"}],"version-history":[{"count":4,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/21492\/revisions"}],"predecessor-version":[{"id":21525,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/21492\/revisions\/21525"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=21492"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=21492"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=21492"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}