Comments on: You should use Core Data /code/you-should-use-core-data/ sealed abstract class drew {} Sun, 27 Mar 2016 22:51:38 +0000 hourly 1 By: Drew Crawford /code/you-should-use-core-data/comment-page-1/#comment-7860 Tue, 26 Mar 2013 07:41:20 +0000 /?p=1408#comment-7860

Since CoreData does not allow the editing of attributes at runtime,

It does, although it’s not something I would recommend trying as a first project. You’re way outside of xcdatamodeld land at that point.

But then again, I wouldn’t recommend it as your first sqlite / MySQL project either, or for that matter for their first custom database implementation. So we’re at solution parity here.

I think the real problem that you face is that arbitrary schema changes are arbitrarily complicated. How do you write queries for arbitrary schemas? How do you do migrations when the schemas change? There are (hopefully!) simple solutions in your specific case, but there are no solutions in the arbitrary case, and you have presented an arbitrary problem. And whether the solutions to your problems are simple or hard doesn’t have much to do with what storage technology you use, as it’s either simple or it’s hard for all the reasonable contenders.

If you really need user-configured arbitrary schema support, you are reading the wrong article. The real problem you face is designing a user interface that sufficiently empowers mobile users to edit their schemas. To the best of my knowledge, this is a completely unsolved problem, even by companies where databases are the core business and are quite motivated to study it. That’s where the focus should be, and your data layer should be whatever crazy implementation that lets you iterate the UI prototype the fastest. Once you’ve got that solution proven is the time to look at how anything is stored.

By: green_knight /code/you-should-use-core-data/comment-page-1/#comment-7813 Wed, 23 Jan 2013 15:34:56 +0000 /?p=1408#comment-7813 Wonderful article, thanks.

(Brief intro: I’m a long-time Filemaker developer (20+ years), just beginning OS X/iOS development, so I’m definitely thinking beyond my current skills).

The application I’m working on right now seems destined for Core Data – it has a very strong database component. Unfortunately it’s a complex scheme that needs a great deal of flexibility – users will want to rethink their classification and the fields they use frequently as their datasets grow and the addition of custom fields is a necessary feature.

Let’s call my base object a ‘record’.

Ordinarily I’d create a Record class and use an NSMutableDictionary to hold the fields for each record so users can make changes on the fly.
Since CoreData does not allow the editing of attributes at runtime, a ‘record’ entity with attributes (instead of keys) doesn’t fulfill my needs. I could stick ‘userDefinableField1-n’ into the model, but that would just mean that most of my users will wish they had n+1 fields to work with. Also, users may want fields for different purposes, including attributed text, numbers, and images, so providing one potential attribute would not be enough.

At this point, I cannot see a way to implement this aspect of my application using CoreData. The idea of having all my data in one big lump in the database and fetched using predicates makes me shudder (though maybe that’s the way to deal with this?) and documentation, including Zarra’s book (which I find somewhat prolematic) don’t give much help with this. At the same time, the model seems almost trivial to design using subclasses of NSObject and I’m still at the time in my programming career where I go <handwave> I’ll solve the problem of performance optimisation later, I just want something that works so I can move on<waves hands again> (this might give you some insight why people don’t use Core Data).

By: Anubis /code/you-should-use-core-data/comment-page-1/#comment-7735 Fri, 28 Sep 2012 10:39:13 +0000 /?p=1408#comment-7735 Hi, nice site and articles.
With my feelings i’am sitting between the two kamps. I’am convinsed that I need CD, but it feels difficult. Like the questions of michael. You claim it is something normal, but for me/us it is hard to figure it out the CD way. Btw I have a sync lib not using CD, but its old. So I need to step up to CD. Also interacting with two different stores in one app, for me it feels like hell. Maybe you can write an article about those two, sync and two stores.
Thank you

By: Using Core Data in your App: Core Data Tutorials & Resources | /code/you-should-use-core-data/comment-page-1/#comment-7717 Sat, 15 Sep 2012 22:38:42 +0000 /?p=1408#comment-7717 […] Drew Crawford at has a pretty interesting article written on July 6, 2012, on why you should use Core Data – you can read it here: /code/you-should-use-core-data/ […]

By: Michael /code/you-should-use-core-data/comment-page-1/#comment-7678 Fri, 10 Aug 2012 06:12:33 +0000 /?p=1408#comment-7678 – Bi-directional synchronization with servers
– Bi-directional synchronization with peers

How does CoreData solve that? Are you referring to the willSave notifications which allows you to implement a synching framework? Or is there built in functionality you are referring to.

By: Carl /code/you-should-use-core-data/comment-page-1/#comment-7641 Thu, 19 Jul 2012 12:03:52 +0000 /?p=1408#comment-7641 thx for the nice article.

i only dismiss CD when i have heavy usage of (INSERT OR REPLACE/UPDATE) and DELETE FROM table;.

By: Drew Crawford /code/you-should-use-core-data/comment-page-1/#comment-7619 Sun, 08 Jul 2012 04:29:06 +0000 /?p=1408#comment-7619 @Phil,

Pro Core Data by Privat is the bible these days, Zarra’s book is dated but still very good.

Claiming that CD’s documentation is bad because NSIncrementalStore’s documentation is bad is like claiming UIKit’s documentation is bad because UITextInputStringTokenizer’s documentation is bad. Both classes are advanced tools for solving advanced problems, and a are a small part of a much larger whole. I wrote the NSIncrementalStore post to tell the advanced CD guys “Hey, you should take a look at this!”. But my discussions with people IRL has often devolved to “Why should I be using CD anyway?”, so it occurred to me that there needed to be a more surfacey discussion of why CD is a good idea to begin with before delving into the One True Architecture conversation.

> The solution with two MOCs is far from obvious.

“Obvious” is subjective. Obvious to you. I came up with it in 30 seconds. (I’m also a CD veteran.)

A lot of the things we programmers do: Cocoa, MVC, ARC, autolayout, UITableView, git, are all “far from obvious”. But they are still incredibly powerful tools to solve incredibly common problems. For something that is a critical part of the toolbelt, “obvious” is not the right criteria. A Keurig coffee maker with one button is great if you just need some coffee, but if you make coffee for a living, you need an expensive espresso machine with the levers and analog pressure meters and hoses and that. I write models code for a living, and anyone in that position needs actual professional-grade tools. Pro tools are not obvious. They are not easy to pick up. They are good. Core Data is good. That’s the claim. Not that it’s easy.

> So you’re basically stuck with going the whole hog.

This is true in the sense that it is true for any database. It makes just as much sense to blame SQLite for its failure to interface with your CD models as it does to blame CD for failure to integrate with your SQLite models. I don’t know what this has to do with one or the other.

Actually, that was a complete lie. You can do cross-domain joins with NSIncrementalStore (but this is “advanced”, and might take me an afternoon). So in a very serious sense, CD is better able to do cross-domain queries with an arbitrary alternate database than SQLite is able to do the same with an arbitrary alternate database. The solution isn’t “obvious”, but it’s a lot easier than it would be cross-joining (say) SQLite with MySQL.

By: Drew Crawford /code/you-should-use-core-data/comment-page-1/#comment-7618 Sun, 08 Jul 2012 03:43:50 +0000 /?p=1408#comment-7618 @Frank, I think if you have a lot of queries that you can share e.g. in a text file that is shared between both platforms, you can potentially get some reduced maintenance burden because new features over here can be more easily ported over there.

But, you have to balance this against, for example, having to roll your own undo support, additional time to performance tune, and so on. There is a class of applications for which this tradeoff is a net positive, but I would say probably not the majority.

By: Frank /code/you-should-use-core-data/comment-page-1/#comment-7614 Sat, 07 Jul 2012 20:20:55 +0000 /?p=1408#comment-7614 I used SQLite because I had to build the same functionality into both an iPhone app and an Android app. Even though I knew I’d have to rewrite the code in Java, I figured that having the same database schema, the same SQL queries, and the same function calls across both platforms would be beneficial. Was I wrong?

By: Phil Jordan /code/you-should-use-core-data/comment-page-1/#comment-7613 Sat, 07 Jul 2012 19:32:14 +0000 /?p=1408#comment-7613 Drew, any chance you could recommend some of those “many, many good books”? Maybe it’s just the recent iOS book goldrush that has produced a bunch of bad books on the subject.

Also, I can’t help pointing out the irony in ” If you haven’t found good documentation, you haven’t looked hard enough,” as a follow-up to “NSIncrementalStore is perhaps the best-kept secret in iOS 5. It doesn’t show up in any advertising materials, barely rates a passing mention in WWDC tech talks, and has the world’s shortest programming guide, at only a few pages. It is so well hidden that I only discovered it very recently.” (from the NSIncrementalDataStore post) :-)

Re: WWDC – noted; if I embark on another project that’s a Core Data candidate, I’ll look through the archives.

Re “staging” objects – yeah, those are the two solutions we encountered. Both give me the creeps as dirty, dirty hacks. The flag doesn’t scale as suddenly the whole rest of the app needs to know about this implementation detail. The solution with two MOCs is far from obvious. Maybe it’s documented somewhere, I don’t know, but I eventually found it in some mailing list post from the early 2000s.

For the hybrid read-only SQLite & read-write CD: does that permit some kind of efficient cross-database JOINs, like raw SQLite does?

> “Well, first of all, I’ve never run into this kind of issue. But you completely can migrate out on a model-by-model basis if you want to. ”

That isn’t a real solution though, is it? If you can’t run queries across your whole data model, that makes it fairly useless. So you’re basically stuck with going the whole hog.