I'm creating a project in Xcode 7.3.1 that uses core data to store a "UserProfile" entity with three attributes. I have set up default values for these attributes but is there any way that I can set it so that a UserProfile entity is created the first time the app is run by default? I will only ever need one of these entities but I will need to access and modify the attributes as the app is used.
Two things about this:
No, there is no way to have an instance of a Core Data entity created by default. Your code must create it.
If you will only ever have one instance, Core Data is a completely inappropriate tool. It makes no sense at all. Store the data in user defaults, or if you prefer, in a separate property list file.
Related
I just want to rename and add attribute on my table for a new version of my app and I want to keep the data if the app was already installed.
Firstly I just set the options:
let options = [NSMigratePersistentStoresAutomaticallyOption:true, NSInferMappingModelAutomaticallyOption:true]
try coordinator.addPersistentStoreWithType(NSSQLiteStoreType, configuration: nil, URL: url, options: options)
And I created a new version model, so if I rename the attributes and add another attributes to my table on the new model, do the app gonna keep the data ?
Per Apple's Core Data Versioning and Migration Guide's section on Lightweight Migrations:
If you rename an entity or property, you can set the renaming identifier in the destination model to the name of the corresponding property or entity in the source model. You set the renaming identifier in the managed object model using the Xcode Data Modeling tool’s property inspector (for either an entity or a property). For example, you can:
... Rename a Car’s color attribute to paintColor
Your code requests automatic lightweight migration. If you want to rename an attribute, migrating like that will not retain data for that attribute. All other data will be retained. Core Data would see it as deleting the old attribute and adding a new unrelated attribute.
If you want to rename an attribute and retain data for that attribute, you can't use automatic lightweight migration. You would need to create a mapping model to tell Core Data how to migrate the data-- specifically, to tell it that the data from the old attribute name should move to using the new attribute name. Once you have more than one version of the mode, you can create a mapping model in Xcode to set this up. The overall process is described in Apple's guide to model migration.
Working with a core data model and I am still new this. Right now I have a view controller that saves the relationship between 2 entities and it stays fine until I have to add another relationship into the primary core data entity. When I do this the relationship between the initial 2 relationships breaks and the tableview is no longer able to present the relationship and thus crashes. I know in order to set the relationship I need to insert it into the already existing context but how do I actually go about that without clearing out the previously set relationhip?
Let's say I have a entity named primary and one named secondary. The relationship between these two sets fine. When I try to set the relationship for the third entity the relationship between the secondary and primary clears out. The real problem is that I am actually passing the object I want to store the relationship into so when I do code similar to this:
passedObject?.relationhips = entity.relation
it isn't actually setting the relationship. Am I missing something? Do I have to insert something into the primary entity context outside of setting the relationship?
A really common core data crash is when you've updated your model but the app on the simulator has data that uses the old model and crashes. So after updating your modal it's a good habit to delete your app from the simulator before running again (although I think Apple made a change in iOS9 where your app will migrate the data automatically but I've not checked that).
If that's not the problem it would help a lot to see a screen grab of your model to see how relationships between your entities are set up.
Because you're new to core data, I'd check to see if the relationship type if 'to one' (the default) or 'to many' (to use if you want a connection between a set of entities instead of just one).
Always check core data subclasses after you have them created automatically by Core Data. Sometimes the setup is incorrect as was the case with my problem.
Can Core Data allow me to create new table programmatically? or if I need that I need to use SQLite directly.
thanks
From a CoreData perspective, you don't really create new tables because database tables are only one possible type of persistence store associated with the core data model.
You can, however, create new core data entities programatically using the NSEntityDescription class. In the NSEntityDescription class documentation you will find this:
Entity descriptions are editable until they are used by an object graph manager. This
allows you to create or modify them dynamically. However, once a description is used
(when the managed object model to which it belongs is associated with a persistent store
coordinator), it must not (indeed cannot) be changed. This is enforced at runtime: any
attempt to mutate a model or any of its sub-objects after the model is associated with a
persistent store coordinator causes an exception to be thrown. If you need to modify a
model that is in use, create a copy, modify the copy, and then discard the objects with
the old model.
I've never tried to modify one at runtime, so I'm not sure exactly how well this works when you have an existing SQLite persistence store, if at all. But it's probably worth playing around with NSEntityDescription to see if it gets you close to what you are trying to do.
You typically create the managed object model graphically using Xcode's Data Model Design tool. (If you wish you can construct the model programmatically at runtime
Core Data programming Guide
You can however:
Create a Object Model Context (outside of the current one you are in/using)
Create one or more Entities
Create a SEPARATE persistent store for that model
Save entities etc...
Close the store when you're done
You can't change models on the fly as they are pretty much fixed when they're pulled into the runtime environment.
Hello fellow stackoverflow family members?
I know it is un-efficient to create one extra sqlite table in iPhone CoreData system. (X)
Currently, My app has one sqlite table but there are preset data to users to no need to waste parse time. But if I adding new entity in current structure of SQLite table, it wipes up the whole preset data. I haven't tried to use immigrate method but I don't think it wouldn't be just adding a new entity on the table. I'm thinking it also wipes up previous preset data.
Current Architecture of SQLite file.
entity : A
attributes : contains data
I want to keep A with attributes still contain data but also add new entity : B.
entity : A
attributes : previous contained data
(PLUS+)
entity : B
attributes : new data
Do I need to create extra persistence set to separately store entity B (create another SQLite file and use as storage) or Is there possible way to add entity B in current SQLite with no changes in entity A?
Thank you.
To directly answer your question: Yes, you can reference multiple SQLite files in Core Data. You'll want to use a unique persistent store for each one.
I don't understand the rest of your question though, so it may be likely that creating multiple persistent stores is not what you want at all.
I know it is in efficient to create one extra sqlite table in iPhone CoreData system.
This is untrue. Creating multiple entities (aka, tables, but that is abstracted away) can lead to much more efficient queries.
Currently, My app has one sqlite table but there is no need to change preset sqlite table but want to add some other attribute.
Just add the attribute to your entity. If your app has already been released or you want to maintain existing data, you'll have to set up a migration and/or turn on lightweight migration.
So commit with new attribute and update coredata is not valid. Because it flash off current data set and need to spend another hours to type manually.
This didn't make any sense to me. Can you clarify?
I have an iPhone Core Data app with a pre-populated sqlite "baseline" database. Can I add a second smaller sqlite database with the same tables as my pre-populated "baseline" database but with additional / complementary data such that Core Data will happily union the data from both databases and, ultimately, present to me as if it was all a single data source?
Idea that I had is:
1) the "baseline" database never changes.
2) I can download the smaller "complementary" sqlite database for additional data as and when I need to (I'm assuming downloading sqlite database is allowed, please comment if otherwise).
3) Core Data is then able to union data from 1 & 2. I can then reference this unified data by calling my defined Core Data managed object model.
Hope this makes sense.
Thanks in advance.
Core Data is designed to handle multiple data files via the – addPersistentStoreWithType:configuration:URL:options:error: method. This will allow you to combine all of the data files together and then access them via a single NSManagedObjectContext.
Your only issue, and it may not even be an issue for you, is that the store files cannot directly reference each other. Therefore you will need to reference data between files "manually" via unique identifiers. However I suspect you are already aware of that limitation.
Manual Relationships
The idea is that when both objects in a "relationship" are in one model and one file, Core Data does its magic and handles all of the referential integrity for you. However when they are in different files and/or models this doesn't happen automatically anymore.
The solution to this issue is to use a fetched property that looks up some unique identifier to retrieve the entity (or entities) that you want to be on the other side of the relationship. This will give you a "weak" relationship between files.
One thing to note though when doing this. The fetched property does not get updated automatically when something changes. This means when data changes that would cause that relationship to change, your application will not be automatically made aware of it and you will need to request that property again to get the updated relationship information.
Hopefully that makes it a bit clearer.
Co-existance of fetched properties and relationships
They can definitely co-exist but realize that they are two separate properties. If you want your controller code to see them as one, then I would suggest building a subclass for that entity and then adding a convenience method in there that hits both the relationship and the fetched property and then rolls them up into one NSArray or NSSet before returning it back to your controller code.
You can attach the downloaded database with ATTACH DATABASE statement and operate with unions of tables.