Why is Core Data so difficult to prepopulate?

This is a more a philosophical question about Apple's design decisions than a question about Core Data.

Why in the world is it useful to have a model system that is so difficult to prepopulate? What are the advantages? I know you can have your program generate the sqlite file and edit it manually, but as far as I can tell, you can't do that if you have any relationships at all.

I compare this to the MVC paradigm used in rails, which seems to make way more sense. Models in rails provide a similar level of abstraction to Core Data (from what I can tell) but they also allow you to enter whatever you want into your database manually (or through a script).

The problem I have with Core Data is that: since rails seems to prove (to me) that you can have an excellent model abstraction from the database while retaining several convenient methods to prepopulate it, what possible advantages does removing that ability offer? Is Core Data somehow more efficient? Is the difficulty involved in prepopulation merely a side-effect of other design choices, and if so, why wasn't prepopulation taken into consideration?

(A disclaimer that I'm genuinely interested in the reasoning behind these choices, and though my post might suggest it, I'm not really looking for a "Models in Rails vs. Core Data" debate.)

Because Core Data is NOT a database. It is an object graph that happens to persist to disk and one of those persistence formats is a database. This means you need to look at it in a reverse PoV.

Core Data is designed to be as fast as possible in retrieving objects from that persistent store and saving them back out. One side effect of this is that the persistent format is focused on making that goal faster and being compatible with anything else is secondary at best. Thus the internal structure of the SQLite file is aimed at performance, not at compatibility.

My opinion about pre-population is that Core Data is designed as a closed loop system. You can use Core Data to populate the data file easily. It is no harder to populate a Core Data SQLite file than it is to write a script to translate your Oracle data to CSV format.

If you stay within Cocoa and Core Data then it is not difficult at all. You write a command line app or editing app and import the data. From the PoV of a Cocoa programmer, that is a trivial task that takes just a few minutes.

It looks like a database ("an organized collection of data for one or more uses, typically in digital form") to me. In any event, none of his question seemed to be predicated on what you call Core Data. He did call it a "model system" at first.

Ken 2010-08-02 16:32:50

Even in the "closed loop system" that is Core Data, prepopulation is a common task. Why create this system without a tool to do so? Or if Apple doesn't want to make it themselves, why specifically have a clause in their license agreement prohibiting the reverse engineering of their Core Data schema so that some enterprising individual could write such a tool themselves?

Evan Cordell 2010-08-02 16:53:48

@Evan Cordell - Apple didn't create a tool for prepopulation in part because it is so easy to do so yourself. See my answers here: http://stackoverflow.com/questions/2248363/portability-of-core-datas-sqlite-file-between-os-x-and-iphone-os/2248463#2248463 and here: http://stackoverflow.com/questions/1264382/how-do-i-initialize-a-store-with-default-data-in-a-coredata-application/1266588#1266588 . I even show how to do this in ~15 minutes in the video for my iPhone course on iTunes U: http://deimos.apple.com/WebObjects/Core.woa/Browse/matcmadison.edu.3989485784.03989485786

Brad Larson 2010-08-02 17:22:56

@Evan Cordell - As far as reverse engineering goes, they consider the internal Core Data format to be private, just like the exact view hierarchy of system display elements. By not committing to an internal structure, this gives them the freedom to change that structure at points in the future to add new capabilities or improve the ones there. Preventing the use of private APIs has been Apple's policy all along, for better or worse, and the same thinking applies here.

Brad Larson 2010-08-02 17:27:29

What defines pre-populating? Is it before the app ever runs that you want a file full of data hanging out, or do you just want some data present when the user first interacts with the app? If you just want the user to have some data to look at right away then just add some entities on first launch or when a new document is created. I've even made it so that the user can decide if new docs have a set of default entities and what those entities are. Sure you have to write a little bit of code, but you can store a lot of the data in an XML file and just read it in.

theMikeSwan 2010-08-02 19:47:49

@theMikeSwan it takes just as long to create a pre-populated SQLite Core Data file as it does to create an XML file and it takes less time to start up because you just copy the file to the documents directory instead of parsing XML.

Marcus S. Zarra 2010-08-02 21:56:46

@Evan Cordell as Brad Larson stated, it is easy, trivial, to create a Core Data loader. Just as easy as it is to create any other data file, you just need to use Core Data to do it.

Marcus S. Zarra 2010-08-02 21:57:27

@Ken his title says Core Data and his tags say Core Data. Thus a Core Data answer. Core Data is an object graph; full stop. The fact that *one* of its persistence options is a database is secondary at best.

Marcus S. Zarra 2010-08-02 21:58:19

@Brad Larson - I realize that it's relatively trivial to write some code to populate Core Data. I take issue with the system because it uses an open standard (sqlite, xml) for the backend without allowing you to interface with it with anything but Core Data. Where is the advantage there? In one of your linked posts you also mention the Core Data Editor program, which I understand to be in violation of apple's license, as per the following warning: "Using this information for reverse engineering to facilitate direct access to the SQLite file is not supported."

Evan Cordell 2010-08-02 22:28:53

@theMikeSwan - I define prepopulating as the former, where data is "hanging out" before the app starts. And your answer sidesteps my question; I understand how populating Core Data is commonly achieved, my question is why the limitions on how that can be done exist.@everyone - Most responses seem to be "It's easy, so why do you care?" but that's not what I'm asking. I'm asking what specific advantages, if any, there are to limiting the direct access to the data. Is the advantage purely on apple's side? It's easier for them?

Evan Cordell 2010-08-02 22:34:39

@Evan Cordell - Where, specifically, in the iPhone Developer Program License Agreement (what I assume you mean by "license agreement") do you see any language about Core Data? I see none here: http://www.eff.org/files/20100302_iphone_dev_agr.pdf What they say in the documentation is that direct access to the SQLite store is unsupported. Unsupported means that you can do this, but they won't guarantee that it will work or keep working in the future, not that you are forbidden by law from doing so. In any case, Core Data Editor uses Core Data and your model files to access the data store.

Brad Larson 2010-08-03 01:50:10

@Evan Cordell I explained why the system is closed in my original answer and Brad elaborated on it in his comments. If you take issue with it, don't use it. There are many benefits to it being closed and that is not going to change any time soon. It is trivial to pre-populate a Core Data persistent store, just as trivial as it would be to do it even if it was open, the only limitation is what tool you get to use to populate it as I have mentioned a few times in this post.

Marcus S. Zarra 2010-08-03 02:16:39

@Brad Larson - You're right, that was my mistake. I read the documentation and took it to mean it was against their policy.

Evan Cordell 2010-08-03 05:22:36

@Marcus S. Zarra - I suppose I was just hoping for more, though I guess asking for benchmarks would've been a bit much. The fact that a persistent store optimized for speed implies a closed system is a bit lost on me. It seems that you can optimize for speed and still have things open, as long as you let people know how you're optimizing. Apple didn't, which is their decision, so I guess that's that. I'm not trying to criticize their policy, merely understand it. I'm marking this answered even though, honestly, Apple's decisions still don't make a lot of sense to me.

Evan Cordell 2010-08-03 05:26:44

ansaurus

tags:

views:

answers:

Why is Core Data so difficult to prepopulate?

related questions