I read this blog where he writes, that everyone should use core data as soon as he want to store more than just trivial data.
So I added a xcdatamodeld to my project. I'm going to fill the database in the app with a formular. And I know, that I will change the data model a lot in the future development. But the entered data in the formular have to be saved. This means I need many migrations. Do you think that it is a good idea to use core data at this stage of development? I don't like the idea having tons of old xcdatamodel files while developing.
By the way, I'm using Magical Record if this helps anyone.
Definitely use core data. It's great.
I don't find that it is worth the effort doing migrations while you're developing the app. Half the time you're not saving the data anyway, or you want to start from a clean slate, or you have data setup code you want to test on the new model.
I'd advise altering your core data stack setup code to simply delete and recreate the persistent store if there is an error. Save the migrations for when you're updating a live version of the app.
Related
The documentation (as of iOS 8) says only lightweight migrations may be performed on an iCloud backed Core Data store. What options are there if one still needs to perform custom migrations afterwards?
Context: we are about to move to iCloud with our Core Data app, but expect future major schema changes what would still need custom migration via mapped fields, etc.
The only option is lightweight migration if you are using iCloud. If you need to do a structural change to the model then it must be doable with a lightweight.
You can do alterations to the data after the migration but the migration itself is stuck as lightweight forever going forward.
If you get stuck then you are left with the option of exporting all of the data (perhaps into another Core Data store) and the importing the data again into iCloud as if it were new.
I am about to undertake the daunting project of converting my live (i.e. already on the app store for a number of years) app from Transformable to Binary Data store for images in Core Data.
I have many users with very large databases that store lots of images. This has really slowed down the Backup/Restore process, and probably caused some other behind-the-scenes issues as well. I didn't know any better when I set it up this way years ago.
How can I undergo this process so as not to lose even one of my customer's images? If it were just me and my own data, I'm sure I could get things working. But I want to be sure to do this properly, step by step, and I knew that this community could be a big help in that area. I really don't know where to start for the existing images.
Basically, I am looking for 1) steps to take, so as not to miss a beat. and 2) general advice, warnings, etc. in this process. I really need a clean migration when this version goes live.
Thanks in advance to anyone who can help.
One piece of advice: don't use "Allows External Storage", especially if you plan to use iCloud syncing with Core Data in the future. Reference: http://www.objc.io/issue-10/icloud-core-data.html
Instead, you might want to consider moving the images into their own files, and saving the URL to those files inside your database instead. You will have to work out how best to do the migration: lightweight migration is probably not an option if you go down this route.
Transformable data type is really just binary under the covers with some additional metadata. Have you tested a simple lightweight migration on an existing store? I suspect the migration would work and would leave the existing data in the store.
If you are looking to get the existing binary data actually moved out of the SQLite file then you are looking at something a bit more involved.
A heavy migration will accomplish what you are looking for but if the stores are large it may take took long and potentially not provide enough feedback for a good user experience. I personally do not use heavy migrations, ever, on IOS but it will accomplish your goal.
An export/import will also work. I generally recommend export/import when a lightweight migration won't work. It involves a medium amount of code but in the end you own the code, understand the entire process and can tweak it to your exact needs.
im learning about core data at the moment, I can see its benefits for apps like a phonebook etc, however is core data good if your app is to contain preloaded data. For example the players of an American football team. I was using MESASqlite and manually entering the ino and then copying and pasting it into xcode to have all the players preloaded in my app.
Basically, I hear core data is not a database (according to the Apple documentation) so im a little confused.
Using CoreData as a read-only pre-loaded data-store is very possible. In fact, CoreData's faulting mechanism may well work in your favour to keep runtime memory consumption low if the dataset is large. Using CoreData is almost certainly easier than fetching sub-sets of records as required from an SQLite database with SQL. CoreData also provides a solution for versioning, and model version updates.
To do this, you use an SQLite backing store and will need to write a tool to populate the initial model. Note that whilst it's just about feasible to use an SQLite database table editor to modify individual fields, you definitely can't create or delete rows using one.
In terms of a tool for populating the initial model, it makes a lot of sense to make this a MacOSX console or Cocoa application and run it as part of the application's build process. You include the SQLite database as a binary resource in your iOS application.
Building a graphical editing tool is actually far easier in MacOSX than iOS because of the extra KVO bindings on many controls provided by the cocoa framework - for instance, in NSTableView.
Alternatively, you can easily convert data from an existing format such as CSV or XML.
I almost always use Core Data, for pre-populated or empty databases. If you have to handle persisted data, you can either use .plist or database (mostly sqlite) files. The difference is that if you use .plist files, you load the data into NSDictionary objects. On the other hand, if you use Core Data, the persisted information is loaded into "managed" objects, wich are easier to work with. You have several advantages using Core Data (manage several contexts, data model editor, caching, etc.)
If you are not familiar with Core Data you should give it a try
Core Data may not truly be a database, but it holds a number of common features with SQLite databases.
Yes, Core Data is a good option. You would generally use an SQLite store to hold the data in your app. You can also write some code or a desktop app which will allow you to edit the preload database. You'd then copy the preload database to your Xcode project.
If you already have a solution using MESASqlite and everything works then there isn't a particular reason to change.
Basically, I hear core data is not a database (according to the Apple
documentation) so im a little confused.
Core Data is an object persistence framework: you put objects into a store, and you can get them back out later. So it's like a database, and it can use a database for the actual storage, but if you're thinking about it in terms of tables and rows instead of object graphs you should maybe consider just using SQLite yourself. Working with objects lets you build the smarts for manipulating your data into your classes, and the objects you pull out of a data store will have those behaviors.
is core data good if your app is to contain preloaded data.
Sure -- it's great for stuff like that. In fact, it's not uncommon to write a simple Mac program that takes data from somewhere else and adds it to a Core Data store using the same model you've created for your iOS app. You can build that data store into your iOS app along with the model, and it'll just work.
Just curious if we can access the core data database through sqlite queries. On the process of searching, I've found Chris Miles' post for debugging core data with sqlite. Here, he points out that we can use the terminal to input sqlite queries and then actually access the core data database.
Kindly clarify if this is possible through objective - c code. If this can be done, may I ask some links for good tutorials I can study on. Thanks!
You can certainly make C sqlite3 calls from inside Objective-C methods. However, if you've gone to the trouble of defining your data model in Core Data and creating a managed object environment, it's hard to imagine why you would want to circumvent that.
Consider also that there's no guarantee that the current table layout under Core Data will stay the same with the next iOS release, so anything your assume about the storage is fragile.
I'm working on a project in which I might need to change my local database, according to information fetched from a server.I've read about Core Data, but from all I saw it uses a pre-defined database structures, and I haven't found a way to alter a table by code with it.I was wondering - should I use Core Data for this use? or should I stick with low-level objective-c wrap for SQLite?Tnx in advance!
I am going to go ahead and say "no, that is not a good idea" mainly because core data requires a lot of generated code to work properly...code which is generated in the XCode environment, not in the application environment.
For example, if you come up with schema for your data, XCode creates data entity objects and links them in specific ways which you shouldn't tamper with. If you were to attempt to alter the schema in real time, you would have to effectively regenerate all those entities and their linkages...which seems impossible. In my experience, any core data schema change requires a clean, delete and reinstall of the application before it will run again as well as resetting the host device's data entirely in some cases to get rid of the old data.
So no...seems unlikely to work.