1

I haven't found an explicit "no" in the documentation/discussion but suspect it is not possible to generate CoreData objects programmatically, at runtime.

What I want to do is similar to executing DDL commands (eg. "Create Table", "Drop Table" etc.) from inside running code, because I don't know until I ask the user how many columns his table needs, or what data types they need to be. Maybe he needs multiple tables, at that.

Does anyone know whether this is possible? Would appreciate a pointer to something to read. (Would also appreciate learning the negative, so I can stop wondering.)

If not doable in CoreData, would this be a reason to switch to SQLite?

user2037606
  • 21
  • 1
  • 5
  • 3
    You can create a Core Data "managed object model" and "entity descriptions" at runtime (see http://stackoverflow.com/a/13744302/1187415 for an example). But note that Core Data is an "object graph manager", not a database (see e.g. http://www.cocoawithlove.com/2010/02/differences-between-core-data-and.html). So with Core Data you should think about objects and their attributes and relationships, not about tables. – Martin R Feb 24 '13 at 11:14
  • I perfectly agree with @MartinR ;) – Lorenzo B Feb 24 '13 at 11:28
  • Thank you very much. I'll study the reference. I also came upon http://stackoverflow.com/questions/6379025/customize-core-data-model-at-runtime/6379098#6379098 just now, which seems to be in the same area (found it a bit too late, sorry :-) ) – user2037606 Feb 24 '13 at 11:45
  • Looks like I can create the CoreData objects dynamically, but have to assign them to a Class (indeed, how else to work with the attributes) which must be defined before runtime. So I guess I cannot really work with CoreData objects (and associated classes) completely made up at runtime. I guess I must implement my own dynamic entity-attribute data model on top of the CoreData objects. That's going to confuse me badly. Thanks for the information above. – user2037606 Feb 24 '13 at 17:09
  • You don't have to create or assign a class. By default they'll be NSManagedObject instances -- to get the properties that you've put on the entities, just use key-value coding ... [thing valueForKey:@"stuff"], [thing setValue:@"other" forKey:@"stuff]; – Greg Combs Mar 27 '14 at 17:20

1 Answers1

4

You can create the entire Core Data model at run time-- there's no requirement to use Xcode's data modeler at all, and there's API support for creating and configuring every detail of the model. But it's probably not as flexible as it sounds like you want it to be. Although you can create new entity descriptions or modify existing ones, you can only do so before loading a data store file. Once you're reading and writing data, you must consider the data model as being fixed. Changing it at that point will generate an exception.

It's not quite the same as typical SQLite usage. It's sort of like the SQLite tables are defined in one fie and the data is stored in another file-- and you can modify the tables on the fly but only before loading the actual data. (I know that's not how SQLite really works, but that's basically the approach that Core Data enforces).

If you expect to need to modify your model / schema as you describe, you'll probably be better off going with direct SQLite access. There are a couple of Objective-C SQLite wrappers that allow an ObjC-style approach while still supporting SQLite-style access:

Tom Harrington
  • 69,312
  • 10
  • 146
  • 170
  • Thanks. This is very helpful. I guess what I'm trying to implement could be described as a graphical database front-end, for people that have no (and don't want any) DB experience. Your response confirms my impression. Thanks again. – user2037606 Feb 25 '13 at 09:23
  • After your managed object model is up and running you can make a copy of it and modify the copy, then switch over to using the new model -- all at runtime. – Greg Combs Mar 27 '14 at 17:21