Reputation:
I'm new to iOS programming, I have a project going on and along with it I constantly learn new features of iOS and so it came to Core Data. I've read through basic tutorials and explanations of it. But sadly they didn't cover well creating a complex database. My goal is to create an application that downloads data files from server which are about 20mb XML files. And loads data from them into App's Core Data database for user to interact with.
I'll try to explain schema im trying to build
Each file is loaded into database as an entity of type A. Each entity A has several properties and an array of entities B. (one to many relationship) Each entity B has several properties and an array of entities C. (one to many relationship)
My XML structure is like
<a>
<set of b's>
<b1>
<set of c's>
<c1>
<c2>
...
<cn>
</set of c's>
</b1>
<b2>
....
<bn>
</set of b's>
</a>
Since entities A simply represent different files that were imported, they are created when i create a listing of available data files on the server. Then i plan to download file, parse it and load it's data into database. When i run my parser, first i get all the data needed to create entity B, then i can either create an array of dictionaries to hold data for entities C, or i can insert entities into B's set.
The part im having troubles with is how to insert entities into MOC and how to save it. I mean should i use same MOC for all kinds of entities and save changes to it? or i should for example insert "B"s into A's MOC, then "C"s into B's MOC and then save at first changes in B's MOC, then at A's MOC?
My parser reads data in chunks, so i need some event to tell it, that i have added all data from current chunk and it's saved and it can start reading next chunk.
I will be grateful for any help there.
Upvotes: 0
Views: 341
Reputation: 2779
Core Data is very powerful framework with all the caching, validation mechanisms for data integrity and optimizations taken care for you. Things that you would have to implement yourself if you wrote our own models from scratch.
However, it is not a relational database and it most certainly is not SQL. Yes, you would most probably use SQLite as the backing store, but you do not get to write SQL statement directly. For most things you need not to anyway.
What comes to storing large data files in the database, it is not recommended for performance considerations. Apple recommends we store URL's to the files in the database and save the data as files to documents directory. To encourage that further they introduced a "shortcut" to core data entity attributes to store data as external reference automatically.
Usage model is simple. Think of MOC as a scratchpad. When you create one, you start with all the data that was available at the time in the persistent store, the database. Then you insert new, modify existing and remove data and whenever you save the MOC the data will be transferred to the persistent store. Or, you just throw it away if you do not want to save the changes. It also supports undo management.
Upvotes: 0
Reputation: 11993
Only use one MOC, pass this around and do everything with it, one save anywhere effects everything at once.
Also you might want to look at why you are using Core Data here, Core Data is handy for actual objects, but if it's purely data you want to store then Core Data has a lot of limitations that you might not be expecting if you are thinking of it as a SQL database.
-
Regarding loading your data into objects. You can just create these A,B,C objects in any order and set the properties and associations between them as you go or later on, it's quite flexible really, just think of them as any other objective-c objects
Upvotes: 1