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.

(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).

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.

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

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.

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.

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.