I am intending to use Core Data to store a static list of data which consist of objects with attributes (e.g. object = person, attributes = weight, height etc).
Any advise on what is the best way to approach this? What raw file format should I need to use and what is the best way to load the data from the raw file to core data?
Appreciate any advise and help on this
If the data set is large, you should include a prepopulated SQLite store in the app bundle.
Create a separate project in Xcode and import the data model and NSManagedObject subclass files (if any.) Write code to import or create the static data and write it all to the persistent store.
Copy/add the persistent store file to the release project. In the release project, set the store pathway to the location of the store file in the app bundle using [NSBundle pathForResourse:Type]. In the persistent store options, mark the store as readonly.
That will let you set up a prepopulated, readonly Core Data stack that will efficiently handle thousands of objects for you.
I'd suggest shipping binary .plist file with initial data and on first launch dump it to CoreData.
Also may I suggest you not use CoreData if your list is going to be immutable. Just read the plist on app startup and keep it in some AppDelegate's instance var.
Update (to reflect comment):
If it's a few thousand records - you SHOULD import it to core data as it would improve the performance of data retreval. Also - I would not suggest keeping ALL of them in the memory.
To get data into plist you could use some other programming language to select all the data from database and export it to xml plist (there are libraries for virtually any programming language). Then by using property list editor you would be able to export it to binary plist.
Then depending on what you need to do with your data - you can import it either in background or just show a progress indicator/bar to the user while using main thread for import. I believe plist would take few MB's. Also - try benchmarking a thousand records just to get approximate estimate of how long data import would take.
1, You could fill in core data on startup from external source. On startup, read data from external source(SQLite database or XML file), then insert the data into core data;
2, Provide pre-filled in SQLite database. For this we’ll let Core Data create the database structure for us based on the model, and then we populate the database with a utility app. The utility app could be a Mac or iPhone app that uses Core Data to populate the database via Core Data APIs, or some kind of program that fills in the SQLite database directly. Once the database is populated, just include it with the app and make the app use it as the default database if no database already exists.
Hope this tutorial will help.
Related
I want to create a large database. I am thinking of using core data for this purpose.But i want to insert the data to it manually and only once. This data is never deleted or edited but only read. How can i use core data to add such large number of objects to database? How to create database in core data and write only once.
Your question is quite general but I'll try to give you some hints on it.
Based on my experience, the simplest way to achieve it, it's to follow these two steps:
1) You could create an external file, in XML, JSON or plist format, that you can parse and use to create a prepulated a Core Data store. You can find some info in core-data-tutorial-how-to-preloadimport-existing-data-updated. In particular, you could set up a dummy project (or just use the AppDelegate methods) and use it to create the store, e.g. MyDataStore.sqlite.
2) Once you created, forget about the routines you have previously used and you ship the store in the application's bundle of your app. There the store is read-only. Otherwise, if you need to modify it, you are not allowed to do it and so you need to move it, for example, to the document directory.
You cand find additional info in the following SO topics:
Is Core Data useful for readonly data too?
How can I ship my app with a pre-populated Core Data database?
Core Data Store included in App Bundle
P.S. If you are in production and you need to make same change to your store, you need to republish the app (since the store is within the main bundle). To avoid this you need to move the store to a different directory and set up, for example, a sort of sync mechanism.
Hope that helps.
I'm pretty new to Core Data, and I'm trying to wrap my head around it.
You might have cases where you want different types of data stored in different places or with different behaviors. For example you might have one read only sqlite store shipped as part of your app containing some default data, an additional store for updates to that data set you have downloaded from a server, and a third for user data. Alternately you might have a case where you want some objects to be persisted while others can live in an in-memory store and do not need to be saved between uses of the app.
I have a mosques database that has 1000 items ..
I want to use Core Data approach in accessing my database ..
I have already tried the SQLite approach to create the database
where I have a text Pad file with all data seperated by tabs
and then Import the data from txt file to sql file ..
Now this works fine ..
I want to know how can I import data from my SQL file to the newly created Core Data Project
Shall I add SQL file to resources ??
Copy it or not ??
I have looked at CoreDataBooks example but I think I'm missing something
I want to know the exact way for adding an SQL file to the resources of a Core Data Project ..
You can't.
You should regard the fact that Core Data uses SQLite as the format to save the file as an implementation detail, not to be used directly unless you really, really, really need to do that. For example, you can't expect Core Data to work alright if you also directly writes on to the SQLite file.
Instead, read the Core Data documentation, and import the data directly from the tab-separated text file to the Core Data context, and let the Core Data save it to the file. Yes it does use SQLite behind the scenes, but it's better for you to forget that fact.
Yuji and Dave DeLong are right on both accounts, however I feel like I should add that just because you can't realistically feed CoreData a pre-populated SQLite file doesn't mean you can't bootstrap your CoreData store from a SQLite file (or a text file or anything else.) It just means that you have to do the work yourself.
For instance, you could include your pre-populated SQLite file (with it's own, non-CoreData schema, etc) as a resource in the project. Then when your app starts up, if it sees that the CoreData store is empty, you can use the SQLite API directly to open/query your bootstrapping database and translate the results into operations that generate the desired object graph in CoreData. The next time the app starts up, the CoreData object graph will be populated, and you won't have to do it again.
The take away here is that while it's not "free," it's not "impossible." Many, many apps include built-in CoreData repositories that contain data. That data had to be bootstrapped from somewhere, right?
I'm wanting to build an app with 2 core data handlers for one iphone app.
The app will be a sports game with pre-filled information. Lets call it prefilledDB as a reference. This prefilledDB will be read-only, I do not want the user to add/edit/delete or change anything in this.
The second db ("gameDB") would have the same core data relationships/models/entities and structure.
When a user selects "New game", it will blank/empty the gameDB and fill it up with the prefilledDB contents, and "Continue game" would just use prefilledDB, assuming it is not empty.
However, I'm not sure if this is the right way to do it. My question therefore is what is the best way to handle this kind of processing. Would an in-built migration system be better than dropping/recreating databases -- or perhaps just using SQLite as the prefilledDB and then filling the gameDB with its contents?
Any help on this would be great.
The prefilled persistent store will have to be readonly if it ships in the app bundle as everything in the app bundle is read only. To make use of the data in a readwrite persistent store, you will need to copy the data to persistent store outside the app bundle e.g. in the documents directory for the app.
You have two ways of doing this:
1) Simplest: Create a new persistent store for each game. In this case you would just copy the prefilled persistent store file from the app directory to the documents directory while in the process renaming it to the current game name. Then you would open that file as the gameDB and it would be automatically populated with the preexisting data. The downside of this system is that you have a large number of files, one for each game, and the data could not be easily shared between them.
2) Best: You use two persistent stores simultaneously in the same context. This is more complicated to set up but gives you greater flexibility. The trick is to create a single abstract subentity e.g. Opponent and then two concrete subentities that are identical save for their names e.g. PreOpponent and GameOpponent. Using the configurations option in the data model, assign PreOpponent to the prefilled persistent store and GameOpponent to the gameDB persistent store. Write some code in the Opponentclass to clone itself to a new GameOpponent instance. When a new game starts, clone all the instances from prefilled to 'gameDB'. All the newly cloned GameOpponent instances will automatically write to the gameDB persistent store.
The advantage of the latter system is that you have all your active data in one readwrite persistent store which you can then manipulate as needed. E.g. you could check previous game or even clone a previous game to create a novel starting point for a new game.
Marcus Zarrus had some code on his site showing how to set up automatic cloning for managed objects.
I developing an app that is read-only. The data has relationships, so I cannot just use a plist or something similar.
Questions:
Should I use Core Data for such a requirement?
If so, how would I enter the data and then release the app with that data?
How would I make it so that the app doesn't need to re-populate a DB every time it loads?
Is there a way to create a Core Data model using sql commands with sqlite (i.e. insert into, etc)?
You may use an SQLite database to accomplish this.
Create the model in your iOS app.
Create and populate the database in a Mac OSX utility command-line app
Copy the sqlite file into your iOS app and link it with some code
Work through these two tutorials, line by line, and afterward you will have a good enough understanding (and code sample) to complete this task in your own app.
Core Data on iOS 5 Tutorial: Getting Started
Core Data on iOS 5 Tutorial: How To Preload and Import Existing Data
In my short experience with the iPhone, you have two options.
Write a data import function and run it on the first application launch.
Use solution 1, but build the initial sqllite file in the simulator, and then on first application launch, copy it into the app's documents directory.
From past experience, option 2 is much quicker for user experience, and the preferred solution.
You can write a utility project that imports the app's data model and use throwaway code n that project to populate the Core Data DB. Once the DB is populated, simply copy the actual file to the app project's resources folder and then when you set up your persistent store, use NSBundle to return the path to the DB file within the built app.
And you're done.